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Preface 



This book contains a selection of tutorials on hot topics in information 
technology, which were presented at the IFIP 18 th World Computer 
Congress. WCC2004 took place at the Centre de Congres Pierre Baudis, in 
Toulouse, France, from 22 to 27 August 2004. 

The 11 chapters included in the book were chosen from tutorials 
proposals submitted to WCC2004. These papers report on several important 
and state-of-the-art topics on information technology such as: 

• Quality of Service in Information Networks 

• Risk-Driven Development of Security-Critical Systems Using UMLsec 

• Developing Portable Software 

• Formal Reasoning About Systems, Software and Hardware Using 
Functionals, Predicates and Relations 

• The Problematic of Distributed Systems Supervision 

• Software Rejuvenation - Modeling and Analysis 

• Test and Design-for-Test of Mixed-Signal Integrated Circuits 

• Web Services 

• Applications of Multi-Agent Systems 

• Discrete Event Simulation 

• Human-Centered Automation 

We hereby would like to thank IFIP and more specifically WCC2004 
Tutorials Committee and the authors for their contribution. We also would 
l ik e to thank the congress organizers who have done a greatjob. 



Ricardo Reis 
Editor 




QUALITY OF SERVICE IN INFORMATION 
NETWORKS 



Augusto Casaca 

IST/INESC, R. Alves Redol, 1000-029, Lisboa, Portugal. 



Abstract: This article introduces the problems concerned with the provision of end-to- 

end quality of service in IP networks, which are the basis of information 
networks, describes the existing solutions for that provision and presents some 
of the current research items on the subject. 

Key words: Information networks, IP networks, Integrated Services, Differentiated 
Services, Multiprotocol Label Switching, UMTS. 



1. QUALITY OF SERVICE IN IP NETWORKS 

Information networks transport, in an integrated way, different types of 
traffic, from classical data traffic, which has flexible Quality of Service 
(QoS) requirements, to real-time interactive traffic, which requires QoS 
guarantees from the network. 

Most of the solutions for the transport of information in this type of 
networks assume that the networks run the Internet Protocol (IP), which 
provides a best-effort service. The best-effort service does not provide any 
guarantees on the end-to-end values of the QoS parameters, i.e. delay, jitter 
and packet loss. However, the best-effort concept results into a simple 
network structure and, therefore, not expensive. 

The best-effort service is adequate for the transport of classical bursty 
data traffic, whose main objective is to guarantee that all the packets, sooner 
or later, reach the destination without errors. This is achieved by running the 
Transmission Control Protocol (TCP) over IP. Services like e-mail and file 
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transfer are good examples of this case. The problem occurs when real-time 
interactive services, such as voice and video, run over IP. In this case, the 
achievement of an end-to-end delay and jitter smaller than a certain value is 
key to achieve a good QoS. This means that the best-effort paradigm needs 
to evolve within IP networks, so that new network models capable of 
efficiently transporting all the types of traffic can be deployed. 

The end-to-end QoS in a network results from the concatenation of the 
distinct QoS values in each of the network domains. In reality, these QoS 
values depend on the QoS characteristics of the different routers and links, 
which form the network. The QoS is basically characterised by the transfer 
delay, jitter and probability of packet loss, all relative to the traffic traversing 
the network. 

The end-to-end delay is caused by the store-and-forward mechanism in 
the routers and by the propagation delay in the links. Jitter, which is defined 
as the end-to-end delay variation for the distinct packets, is caused by the 
different time that each packet remains in the router buffers. Packet loss 
basically results from congestion in routers, which implies the discard of 
packets. 

The evolution of the best-effort paradigm to improve the end-to-end QoS 
in an IP network can be achieved by doing resource allocation at the router 
level, by intervening in the routing mechanism and by traffic engineering in 
the network. All these actions can be performed simultaneously in a network 
or, alternatively, only some of them can be implemented, depending on the 
QoS objectives. In the following text we will analyse these different 
mechanisms. 

The router structure in traditional best-effort networks, which is shown in 
figure 1, is very simple. 



Input 

Ports 



Control 

Unit 



Forwarding 

Unit 



l Output 
Ports 



Figure 1. Best-effort router 
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The input ports accept packets coming from other routers and the output 
ports forward packets to other routers along the established routes. The 
forwarding unit sends each packet to the appropriate output port based on the 
IP destination address of the packet. For this purpose there is a routing table, 
which maps the destination address into the output port. The control unit is 
in charge of managing the forwarding unit. The routing protocol runs in the 
control unit. 

To improve the QoS capabilities of the router, different mechanisms need 
to be implemented, which will result into a more complex structure for the 
router. These mechanisms are the following: classification, policing, 
marking, management of queues and scheduling [1]. 

Each traffic class, which requires bounded values for the end-to-end 
delay, jitter and packet loss, independent of the remaining traffic, needs a 
separate queue in the router. When a packet arrives at the router it needs to 
be classified and inserted into the respective queue. Also, after classifying a 
packet, it must be decided if there are enough resources in the queue to 
accept the packet. The policing mechanism is in charge of this action. A 
decision can also be taken in order to accept the packet conditionally, i.e. to 
mark the packet and discard it later in case of necessity. Each queue must 
have its own policy for packet discard depending on the characteristics of the 
traffic served by the queue. This is done by the queue management 
mechanism. Finally, a scheduling mechanism is required to decide on the 
frequency of insertion of packets into the output port that serves several 
queues. 

Each of the referred mechanisms results into a new functional block in 
the router. QoS-capable routers are definitely more complex than best-effort 
routers, but must be able to inter-operate with them, because according to the 
Internet philosophy, incremental changes in one part of the network should 
be done without impact in the remaining parts of the network. 

These QoS-capable routers are required for the new IP network models, 
namely Integrated Services (IntServ) and Differentiated Services (DiffServ), 
which need to allocate resources in the network routers for the distinct types 
of traffic classes. These network models will be explained later in this 
article. 

The Internet routing is based on the shortest-path algorithm. Based on the 
IP address of the destination, this algorithm establishes a route between 
source and destination by using the shortest-path according to a well defined 
metric, for example, the number of routers to be traversed or the cost of the 
different routes. The algorithm is very simple, but it might cause an over- 
utilization of certain routes, leaving others free, when the network is highly 
loaded. This over-utilization results in extra delays and, in some cases, 
packet losses. An alternative is to use QoS-based routing, which originates 
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multiple routing trees, in which each free uses different combinations of 
parameters as the metric. This allows having different routes for the same 
source-destination pair according to the characteristics of the traffic. For 
example, one route could have delay as the metric and other route could 
have cost. The first one would be more appropriate for interactive traffic and 
the second one for bursty data traffic. 

Finally, traffic engineering allows the network operator to explicitly 
indicate the use of certain routes in the network, also with the aim of 
achieving route diversification for the different traffic classes. Although 
traffic engineering uses techniques, which are different from the ones 
employed by QoS-based routing, if used in a network, can achieve by itself 
some of the objectives of QoS-based routing. 



2. RESOURCE ALLOCATION MECHANISMS IN 

ROUTERS 

As seen in the previous chapter, QoS-capable routers require the 
implementation of a number of additional mechanisms besides the ones 
provided in best-effort routers, namely classification, policing, marking, 
management of queues and scheduling. 

2.1 Classification of packets 

The selection of the input queue where to insert a packet arriving to a 
router depends on the packet class. The classification of the packet is based 
on n bits existing in the packet header. These n bits constitute the 
classification key and, therefore, up to 2 n classes can be defined. 

Some complex classification schemes can consider several fields in the 
packet header to perform the classification, e.g. source address, destination 
address and TCP/UDP ports. Flowever, the normal case only considers a 
single field in the header. In IP version 4 (IPv4) it is the TOS byte [2], in IP 
version 6 (IPv6) it is the TC byte [3]. To further simplify the classification 
scheme the semantics adopted for both versions of IP follows the one 
defined for the IP Differentiated Services (DiffServ) model [4], This is one 
of the new models for IP networks having in view an improvement of the 
best-effort model as it will be studied in chapter 4. In the DiffServ model, 
the field equivalent to the TOS (IPv4) and TC (IPv6) is called the DiffServ 
field. It is one byte long and its structure is indicated in figure 2. 
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0 ... 5 6 7 



DSCP 



cu 



DSCP: DiJJServ Code Point 
CU: Currently Unused 



Figure 2 . The DijfServ field 



The 6 bits of the DSCP permit to define up to 64 different classes. 

2.2 Policing and marking 

Every class puts some limits on the timing characteristics of packet 
arrival. This consists on limiting the maximum allowed arrival rate and the 
maximum number of packets that can arrive within a certain time interval. 
The router polices the arrival of packets and can do one of two actions for 
the packets that do not respect the timing limits (out-of-profile packets), 
either eliminates all the out-of-profile packets, or marks them and lets them 
go into one of the router queues. The marking of packets allows that, in case 
of being necessary to drop packets in the queue, the marked ones might be 
selected to be the first ones to be discarded. The marking indication is given 
by a bit in the packet header. 

The action of policing requires that the router is able to measure the 
timing characteristics of packet arrival so that it can decide whether the 
packets are in-profile or out-of-profile. These measurements are usually 
done by using the token bucket technique. 

The best way to explain the token bucket technique is to symbolically 
consider that we have a bucket and tokens that are inserted or extracted from 
the bucket. The tokens are inserted into the bucket at the rate of x tokens/s 
and a token is removed from the bucket whenever a packet arrives at the 
router. The bucket has a capacity of k tokens. When a packet arrives, if there 
is at least one token to be extracted from the bucket, the packet is considered 
to be in-profile, but if the bucket is empty, the packet is considered out-of- 
profile. This technique allows the acceptance of bursty traffic up to a certain 
limit on the duration of the burst. The policing action can be followed by 
marking or not, this depending on the router implementation and also on the 
classification of the packet. 
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2.3 Management of queues 

The router queue manager is responsible for the establishment and 
maintenance of the queues in the router. 

The functions of the queue manager are: i) to insert a packet into the 
queue related to the packet class if the queue is not full; ii) to discard the 
packet if the queue is full; iii) to extract a packet from the queue when 
requested by the scheduler; iv) optionally, to perform an active management 
of the queue by monitoring the queue fdling level and try to keep that filling 
level within acceptable limits, either by discarding or by marking packets. 

An active management of the queues, although optional, is a 
recommended practice, as it allows accepting some traffic bursts without 
losing packets and can also diminish the packet delay in the router. There are 
several techniques to actively manage the router queues. We will mention 
some of the most relevant ones, namely. Random Early Detection (RED), 
Weighted RED (WRED) and Adaptive RED (ARED). 

It is known that the best solution to control the filling level of a queue 
shared by different flows of packets is to statistically generate feedback 
signals, whose intensity is a function of the average filling level of the queue 
[5]. 

The RED technique [6] utilizes the average filling level of the queue, as a 
parameter for a random function, which decides whether the mechanisms 
that avoid the queue overload must be activated. For a queue occupancy up 
to a certain threshold (min), all the packets remain in the queue. For a filling 
level above min, the probability of discarding packets rises linearly until a 
maximum filling level (max). Above max all the packets are discarded. The 
average filling level is recalculated whenever a packet anives. 

The WRED technique uses an algorithm that is an evolution of RED by 
“weighting” packets differently according to their marking. The RED 
algorithm still applies, but now the values of min and max depend on the 
packet being marked or not. For marked packets the values of min and max 
are lower than for unmarked ones, therefore, there is a more aggressive 
discard policy for the marked packets. 

Finally, the ARED technique is also based on an algorithm derived from 
RED. In this case, the RED parameters are modified based on the history of 
occupancy of the queue. ARED adjusts the aggressiveness of the probability 
of packet dropping based on the more recent values of the average filling 
level of the queue. This provides a more controlled environment for the 
management of the queue occupancy. 
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2.4 Scheduling 

Scheduling is the mechanism that decides when packets are extracted 
from the queues to be sent to a router output port. There are different degrees 
of complexity for the implementation of schedulers. The simplest ones have 
the only objective of serving queues in a certain sequence, without caring 
about the output rate of each queue. The more complex schedulers have the 
objective of guaranteeing a minimum rate for certain queues and 
continuously adapt its serving sequence for this puipose. 

The simplest schedulers are the Strict Priority schedulers. The queues are 
ordered by decreasing priority and a queue with a certain priority is only 
served if the queues with higher priority are empty. To avoid that the queues 
with less priority are never served, the upstream routers must have 
mechanisms of policing to assure that the higher priority queues are never 
working at full capacity. If the scheduler is busy and a packet arrives at a 
higher priority queue, the scheduler completes the present transmission and 
only then serves the higher priority queue. This a useful mechanism for 
services that require a low delay. The maximum delay value depends on the 
output link speed and on the maximum length of the packet. 

Another simple scheduling mechanism is the Round Robin. The 
scheduler serves the queues in a cyclic order, transmitting one packet before 
serving the next one. It jumps over empty queues. In Round Robin it is 
difficult to define limits for delays, but it assures that all the queues are 
served within a certain time. 

The Strict Priority and Round Robin mechanisms do not take into 
consideration the number of bits transmitted each time a queue is served. As 
the packets have variable length, these two mechanisms cannot be used to 
control average rates for the different traffic classes. The control of the rates 
requires that the service discipline of the scheduler adapts dynamically to the 
number of bits transmitted from each queue. 

The Deficit Round Robin (DRR) scheduling mechanism [7] is a variant of 
the Round Robin. It considers the number of bytes transmitted from a certain 
queue, compares that number with the number of bytes that should have 
been transmitted (to achieve a certain rate) and takes that difference as a 
deficit. This deficit is used to modify the service duration of the queue the 
next time it is served. 

Weighted Fair Queueing (WFQ) [8] is also a variant of Round Robin. It 
continuously recalculates the scheduling sequence to determine the queue 
that has more urgency in being served to meet its rate target. It also gives 
different weights to each queue. In WFQ and DRR the average rates are only 
achieved after the transmission of many packets. 
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3. THE INTEGRATED SERVICES MODEL 

The Integrated Services (IntServ) model was the first network model to 
be considered to improve the IP best-effort network towards the support of 
real-time services. This model is defined in [9]. Integrated Services is 
explicitly defined as an Internet service model that includes best-effort 
service, real-time service and controlled link sharing. Link sharing means to 
divide the traffic into different classes and assign to each of them a minimum 
percentage of the link bandwidth under conditions of overload, while 
allowing unused bandwidth to be available at other times. 

Besides the best-effort service, there are two other classes of service 
supported: Guaranteed Service [10] and Controlled Load Service [11]. The 
Guaranteed Service (GS) is for real-time applications with strict 
requirements for bandwidth and delay. The Controlled Load (CL) service is 
for applications that require a performance equivalent to the one offered by a 
best-effort network with a low traffic load. 

The IntServ model requires the processing of the traffic in every router 
along an end-to-end path and also requires a signalling protocol to indicate 
the requests from each flow. A flow is defined as a set of packets from a 
source to one or more receivers for which a common QoS is required. This 
might apply to packets that have the same source/ destination addresses and 
port numbers. 

The IntServ model consists of a sequence of network elements (hosts, 
links and routers) that, altogether, supply a transit service of IP packets 
between a traffic source and its receivers. If there is a network element 
without QoS control it will not contribute to the IntServ. Before sending a 
new flow of packets into the network, there must be an admission control 
process in every network element along the end-to-end path. The flow 
admission is based on the characterisation of the traffic made by the source. 

The IntServ applications are classified in real-time tolerant, real-time 
intolerant and elastic. As suggested by the name, tolerant real-time 
applications do not require strict network guarantees concerning delay and 
jitter. In elastic applications the packet delay and jitter in the network are not 
so important. 

The GS service provides firm bounds on end-to-end delays and it is 
appropriate for intolerant real-time applications. An application indicates its 
expected traffic profile to the network, which evaluates the end-to-end 
maximum delay value that can guarantee and gives that indication to the 
application. The application decides whether that delay value is adequate 
and, in the affirmative case, proceeds by sending the flow of packets. 

The CL service is defined by the IETF as a service similar to the best- 
effort service in a lightly loaded network. This service is adequate for real- 
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time tolerant and elastic applications. Of course, many of the elastic 
applications can also be adequately served by the best-effort service. 

The signalling protocol is a key element in the IntServ model, as it is 
used for doing resource reservation in the network routers. The signalling 
protocol makes resource reservation in two steps. The first one is admission 
control and the second one is configuration of the network elements to 
support the characteristics of the flow. The Resource Reservation protocol 
(RSVP) [12] has been selected as the signalling protocol for IntServ. 

As schematically shown in figure 3, sources emit PATH messages to the 
receivers. Each PATH message contains two objects, Sender_Tspec and 
Adspec, respectively. The first object is the traffic descriptor and the second 
one describes the properties of the data path, including the availability of 
specific QoS control characteristics. The Adspec object can be modified in 
each router to reflect the network characteristics. The receivers reply with 
RESV messages to the source. A RESV message carries the object 
Flowspec, which contains the QoS expected by the receiver and to be 
applied to the source traffic. 



PATH 




Figure 3. RSVP operation 



To start a reservation, the source of the flow defines the Sender _Tspec 
and Adspec parameters and inserts them in a PATH message. At the 
receivers, Sender _T spec and Adspec are used to determine the parameters to 
send back in the Flowspec object. In Flowspec it is indicated whether CL or 
GS is selected and it also carries the parameter's required by the routers along 
the path, so that they can determine whether the request can be accepted. 
RSVP is appropriate for multicast operation. 

All the routers along the path must do local measurements, followed by 
policing, so that the agreed bounds can be achieved. The resource 
reservation mechanism is independent of the routing algorithm. The RSVP 
messages circulate along the routes previously established by the routing 
algorithm. 
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4. THE DIFFERENTIATED SERVICES MODEL 

The IntServ model is conceptually a good model to support both the real- 
time and non-real-time services in the Internet. However, in practice, this 
model is not scalable for the Internet. Its deployment would require to keep 
states in the routers for every flow and also to process these flows 
individually, which is very difficult to achieve. This was the main reason for 
the definition of another IP network model, the Differentiated Services 
(DiffServ) model [13]. DiffServ represents an incremental improvement of 
the best-effort service. It is a minimalist solution compared to IntServ, but it 
is scalable. 

The DiffServ network structure is shown in figure 4. A network has edge 
and core routers. The edge routers map the customer’s traffic into the core 
routers, whose main function is to transport packets to other routers until the 
egress edge router. The egress edge router communicates with the 
customer’s terminal. 



Edge router 




Figure 4. The DiffServ network model 



The edge routers classify and police the customer's traffic before sending 
it to the network. The edge routers can refuse requests, therefore, transitory 
overloads can be solved. The more complex decisions are taken in the edge 
routers, simplifying the structure of the core routers, which implies that we 
can have faster core routers. Also we will have a smaller number of states 
than in IntServ as the packet context is established only from the DSCP field 
(see figure 2). The classification done in the edge routers allows that a large 
variety of traffic can be mapped into a small set of behaviours in the core 
network. In the DiffServ terminology, a collection of packets with the same 
DSCP is called DiffServ Behaviour Aggregate. 
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DiffServ introduces the concept of Per Hop Behaviour (PHB). Basically 
the PHB is the specific behaviour of the queue management and scheduling 
mechanisms in a network element. The concatenation of the different PHBs 
between an ingress and an egress edge router in the network defines the 
expected behaviour of the network and permits to define a Service Level 
Agreement with the customers. 

DiffServ supports two distinct classes of PHBs besides best-effort. They 
are named Expedited Forwarding (EF) [14] and Assured Forwarding (AF) 
[15]. They are distinguished by the different coding values of the DSCP 
field. All bits with the value 0 in DSCP means a best-effort PHB. 

EF PHB is defined by the code 101110 in the DSCP. This PHB is the 
most stringent one in DiffServ and is used for services that require low 
delay, low jitter and small packet loss. EF PHB requires co-ordination 
among the mechanisms of policing and scheduling along the path to be used 
by the EF packets. This service is sometimes also known as Premium 
service. 

The AF PHB is less stringent than EF and is specified in terms of relative 
availability of bandwidth and characteristics of packet loss. It is adequate to 
support bursty traffic. In AF there are two types of context encoded in the 
DSCP: service class of the packet and precedence for the packet loss. The 
service class of the packet defines the router queue where it will be inserted. 
The loss precedence influences the weight allocated to the queue 
management algorithm, making this algorithm more or less aggressive 
towards packet discarding. 

The first three bits of DSCP define the service class and the next two bits 
define the loss precedence. The sixth bit is fixed at 0. The standard defines 
four service classes and three loss precedence levels as shown in table 1. 
More classes and precedence levels can be defined for local use. 





Class 1 


Class 2 


Class 3 


Class 4 


Precedence 1 (low) 


001 010 


010010 


Oil 010 


100010 


Precedence 2 (medium) 


001 100 


010 100 


011 100 


100 100 


Precedence 3 (high) 


001 110 


010 110 


011 110 


100 110 



Table I. DiffServ classes and loss precedence levels 



As the AF PHB is the one advised for the support of data applications, it 
is important to understand the interaction of this mechanism with TCP. 
Some authors claim that some improvements need to be done at the DiffServ 
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level in order that TCP performance is not diminished [16]. This is a subject 
that requires further study. 

The DiffServ model is simple and, therefore, attractive for deployment in 
the Internet. However, the mapping of a large number of flows into a 
limited number of PHBs requires techniques that are very dependent on the 
network topology and QoS characteristics of the routers, namely the 
classification, queue management and scheduling mechanisms. 



5. INTEGRATED SERVICES OVER DIFFSERV 
NETWORKS 

The IntServ model supports the delivery of end-to-end QoS to 
applications in an IP network. An important factor, however, has not allowed 
a large deployment of IntServ in the Internet. It has to do with the 
requirement for per-flow state and per-flow processing, which raises 
scalability problems. 

On the other hand, the IntServ model is supported over different network 
elements. A DiffServ network can be viewed as one of these network 
elements, which exist in the end-to-end path between IntServ customers. As 
we know, the main benefit of DiffServ is to eliminate the need of per-flow 
state and per-flow processing and, therefore, making it a scalable model. In 
this context, IntServ and DiffServ can be used together to create a global 
end-to-end solution. In this global solution it is possible to have IntServ 
signalling between the hosts and the ingress router to the DiffServ network 
so that the router can indicate to the host whether there is enough network 
capacity to transport the packets related to the service. This capacity is 
provisioned during the configuration of the DiffServ network. The state 
information is only treated at the IntServ level. 

The IntServ/DiffServ network configuration is shown in figure 5 [17]. 




IntServ region Diffserv region IntServ region 



Figure 5. Reference IntServ/DiffServ configuration 

The model distinguishes between edge routers (ER) and border routers 
(BR). Edge routers are egress/ ingress routers in the IntServ regions. Border 
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routers are ingress/ egress routers in the DiffServ regions. The border routers 
are the ones that map the DiffServ ingress traffic into the network core 
routers (not represented in the figure). The RSVP signalling generated by the 
hosts is carried across the DiffServ regions. The signalling messages may be 
processed or not by the DiffServ routers. If the DiffServ region is RSVP- 
unaware, the border routers act as simple DiffServ routers, doing no 
processing of the RSVP messages. Edge routers do the admission control to 
the DiffServ region. If the DiffServ region is RSVP-aware, the border 
routers participate in RSVP signalling and do admission control for the 
DiffServ region. 

This model to support QoS in an IP network is an attractive compromise, 
but some additional work still needs to be done, mainly concerned with the 
mapping of IntServ services to the services provided by the DiffServ 
regions, with the need for the deployment of equipments, named bandwidth 
brokers, that can provide resources in a DiffServ region in a dynamic and 
efficient way and for the support of multicast sessions with this network 
model [18]. 



6. MULTIPROTOCOL LABEL SWITCHING 

Multiprotocol Label Switching (MPLS) provides traffic control and 
connection-oriented support to IP networks. These capabilities allow the 
provision of a basic connection-oriented mechanism to support QoS, ease the 
provision of traffic engineering in the network and also support the provision 
ofVirtual Private Networks at the IP level [19]. 

MPLS must be clearly distinguished from the IP network models 
(IntServ, DiffServ) previously defined. The IntServ and DiffServ models are 
defined at the IP level, whereas the MPLS protocol runs below the IP level. 
MPLS configures the network to transport IP packets in an efficient way. 

MPLS was preceded by other technologies, namely IP Switching from 
Ipsilon, ARIS from IBM, Tag Switching from Cisco and CSR from Toshiba. 
These different technologies had aims similar to MPLS and now they have 
been superseded by the MPLS standard defined at IETL [20]. 

IP packets are partitioned into a set of the so-called Lorwarding 
Equivalent Classes (EEC). As defined in the standard, a particular router will 
consider two packets to be in the same EEC if there is some address prefix X 
in that router’s routing tables such that X is the longest match for each 
packet’s destination address. All packets which belong to a certain EEC and 
which travel from a particular node will follow the same path in the network. 
In MPLS, the assignment of a certain packet to a EEC is done at the network 
entry. The EEC is encoded as a label, which is appended to the packet 
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header. This label is used in the network to switch the packets in the 
different routers which are MPLS-capable. These MPLS-capable routers are 
named Label Switching Routers (LSR) and have switching tables that 
operate using the packet label as an index to a table entry, which determines 
the next hop and a new label. MPLS simplifies the forwarding of packets in 
the network and allows explicitly sending a packet along a certain existing 
route. This latter technique is known as traffic engineering. 

The MPLS label is a 32-bit field as shown in figure 6. The first 20 bits 
define the label value, which is defined at the network entry depending on 
the FEC to which the packet belongs. The label value has only local 
significance. It is changed by the LSRs in the switching process. The 
experimental bits are reserved for local use, the stack bit is used when labels 
are stacked and the Time to Live (TTL) field establishes a limit for the 
number of hops. The TTL field is important because the usual TTL function 
is encoded in the IP header, but the LSR only examines the MPLS label and 
not the IP header. By inserting TTL bits in the label, the TTL function can be 
supported in MPLS. If MPLS runs over a connection-oriented layer 2 
technology, such as ATM or Frame Relay, the label value is inserted in the 
VPFVCI field of ATM or in the DLCI field of Frame Relay. 
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Figure 6. MPLS label format 

The operation of MPLS can be described as follows. Initially, a path must 
be established in the network to send the packets of a given FEC. This path 
is known as Label Switched Path (LSP). The establishment of the LSP can 
take into consideration the resource allocation to be done in the network 
routers having in view the support for QoS provision. To establish this path, 
two protocols are used. The first one is the routing protocol, typically OSPF, 
which is used to exchange reachability and routing information. The second 
one is used to determine which route to use and which label values must be 
utilised in adjacent LSRs. This latter protocol can be the Label Distribution 
Protocol (LDP) or an enhanced version of RSVP (RSVP-TE). Alternatively, 
instead of using LDP or RSVP-TE, an explicit route can be provisioned by a 
network operator, which will assign the adequate label values. 
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When a packet enters the MPLS domain, the LSR assigns the packet to a 
certain FEC, and implicitly to an LSP, and inserts the MPLS label into the 
packet. The next action is to forward the packet. Within the MPLS domain, 
when an LSR receives a packet, the switching table is accessed, the label is 
substituted by a new one and the packet is forwarded to the next hop. Finally 
the egress LSR removes the label, examines the IP header and forwards the 
packet to the destination. 

MPLS can be used to efficiently support the transport of packets in a 
DiffServ network [21]. At the ingress of a DiffServ network the IP packets 
are classified and marked with a DSCP, which corresponds to their 
Behaviour Aggregate. At each router the DSCP is used to select the 
respective PHB. RFC 3270 specifies how to support the DiffServ Behaviour 
Aggregates whose corresponding PHBs are currently defined over an MPLS 
network. It specifies the support of DiffServ for both IPv4 and IPv6 traffic, 
but only for unicast operations. The support of multicast operations is 
currently under study. 



7. QUALITY OF SERVICE IN THIRD 

GENERATION WIRELESS NETWORKS 

Third Generation wireless networks, also known in Europe as Universal 
Mobile Telecommunications System (UMTS), are a good example of 
information networks. Whereas second generation wireless networks were 
optimized for the communication of voice, third generation networks focus 
on the communication of information, including all the types of services. 
This requirement to transmit information in all its forms implies that the 
circuit switched based network architecture of second generation networks 
has to include also a packet switched paid in its evolution towards a third 
generation network architecture. 

The UMTS network architecture has been defined by 3GPP (Third 
Generation Partnership Project). 3GPP has planned the evolution of the 
network according to a series of releases. The first one to be implemented is 
known as Release 99 [22]. A simplified view of the UMTS architecture, 
according to Release 99, is shown in figure 7. 
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Figure 7 . UMTS network architecture 



The structure of a UMTS network consists of two main levels: radio 
access network and core network. They are separated by the lu interface. 

The Universal Terrestrial Radio Access Network (UTRAN) consists of a 
set of Base stations, known as nodes B, and a set of Radio Network 
Controllers (RNC). Each RNC controls a number of nodes B. lub is the 
interface between a node B and an RNC. The RNCs may communicate 
between themselves via the Iur interface. The radio access part is comprised 
between the User Equipment (UE) and the nodes B (interface Uu). The RNC 
is the switching and control element of the UTRAN. Each RNC is 
respectively connected, via the lu interface, to the Mobile services Switching 
Centre (MSC) and Serving GPRS Support Node (SGSN), which are two 
elements of the Core network. 

The Core network consists of a circuit switched domain and a packet 
switched domain. The main elements in the circuit switched domain are the 
MSC and the Gateway MSC (GMSC). The MSC is responsible for the 
circuit switched connection management activities. The GMSC takes care of 
the connections to other PSTN networks. In the packet switched part, there 
are also two main elements, the SGSN and the Gateway GPRS Support 
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Node (GGSN), separated by the Gn interface. The SGSN supports packet 
communication towards the access network and is responsible for mobility 
management related issues. The GGSN maintains the connections towards 
other packet data networks, such as the Internet, via the Gi interface. The 
Home Location Register (HLR) contains the addressing and identity 
information for both the circuit and packet switched domains of the core 
network. 

The problem of QoS provision in UMTS is particularly relevant for 
mobile packet switched based services, which constitute the main novelty 
introduced in UMTS networks compared to the previous generation of 
circuit switched wireless networks. The Core network circuit switched 
domain uses signalling protocols inherited from GSM. The Core network 
packet switched domain can be seen as an IP backbone internal to the 
operator network. 

The end-to-end services are carried over the network using bearers. A 
bearer is a service providing QoS between two defined points. As the radio 
access network and core network have their own QoS properties, the QoS 
needs to be treated separately in each of these levels. The end-to-end QoS is 
the global result, which takes into account the distinct levels of the network. 

In UMTS a specific medium access control protocol is used on the radio 
bearers, which link the UEs to the base stations. From the base stations to the 
core network, the transport of packets is done over ATM. In the core 
network, the information is encapsulated in IP; here, the QoS is treated 
according to the DiffServ model. The layer 2 protocols in the core network, 
which will transport the IP packets, are not standardized, although, in 
practice, ATM might be one of the main choices of network operators for 
this purpose. 

In UMTS there is one additional feature, which consists in the UEs 
having the ability to negotiate the QoS parameters for a radio bearer. The 
negotiation is always initiated by the application in the UE and the network 
checks whether it can provide the required resources or if it rejects the 
request. 

After the deployment of release’99, new releases are foreseen to upgrade 
UMTS networks in the future [23] [24], The upgrade of the UMTS network 
aims, in a first phase, to evolve the whole core network into a packet 
switched architecture based on IP. This means that we will have voice over 
IP in the core network after the first phase of evolution is accomplished. The 
final aim is to have an “All-IP” network including the radio part. Therefore, 
we would have an end-to-end IP network to support the applications. Of 
course, this network would need to consider all the aspects covered in the 
previous chapters of the paper to achieve a satisfactory QoS for all types of 
services. Although this is the aim, it might still take some time to achieve it, 
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due to the characteristics of the air interface, where the bandwidth 
availability is at a premium, which requires optimization of the mechanisms 
to provide QoS. 



8. CONCLUSIONS 

The problem of provisioning QoS in information networks is not 
completely solved yet. As seen in the previous chapters, the evolution of an 
IP best-effort network into a network that can provide QoS guarantees is not 
an easy task. Some significant steps have already been given, but research 
continues active in this field. As described next, the use of signalling 
protocols, the evolution towards IPv6 and the convergence of IP with 
existing networks are good examples of current research work in this area. 

As we know, resource allocation in the network elements is required to 
comply with bounds in the values of the different QoS parameters. Resource 
allocation can be done by provisioning the network, but provisioning is 
neither flexible nor dynamic. Network operation would be more effective if 
a dynamic and flexible solution based on signalling could be implemented. 
One of the protocols that is often referred for this puipose is RSVP. Some 
extensions have been proposed to RSVP to provide additional features, 
namely security, more scalability and new interfaces. One well-known 
extension is the so-called RSVP-TE, which is used in MPLS to establish 
explicitly routed LSPs. Other protocols have also been proposed, such as 
YESSIR and Boomerang [25]. All these signalling protocols apply to the 
intra-domain level. If we wish to consider also inter-domain signalling, 
which is the global scenario, other signalling protocols need to be 
considered. BGRP is a signalling protocol for inter-domain aggregated 
resource reservation for unicast traffic [26]. Other inter-domain protocols 
under study are SICAP [27] and DARIS [28]. The comparative efficiency of 
all these protocols to serve the different types of services is under evaluation 
[29], 

Currently, IP networks use IPv4. A new version of the protocol (IPv6) is 
ready since about ten years ago. Although the main new feature of IPv6 is a 
larger IP addressing space (128 bits instead of 32 bits), there are also new 
fields in the IP header that can be used to facilitate the QoS support. 
However, the introduction of IPv6 in the existing networks has not been 
done yet at a large scale. The best strategy of introducing IPv6 in the running 
networks is still under discussion as well as the best way of taking advantage 
of its new features [30] [31]. 




Quality of service in Information Networks 



19 



The support of the convergence of IP networks with other networks, such 
as the PSTN, is key to the success of information networks. This is an issue 
that has been under study in standardization bodies, namely at the ITU-T 
[32]. There is a need to coordinate the sharing of resources, which are done 
with different signalling protocols, in distinct operating domains. 

Many other items related to the evolution of IP-based information 
networks are currently under study in several research projects, e.g. [33] and 
in standardization bodies, namely the IETF [34]. This study has a broad 
spectrum and extends from routing and transport to security issues in IP- 
based networks. 
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Abstract Despite a growing awareness of security issues in distributed comput- 
ing systems, most development processes used today still do not take 
security aspects into account. To address this problem we make use 
of a risk-driven approach to develop security-critical systems based on 
UMLsec, the extension of the Unified Modeling Language (UML) for 
secure systems development, the safety standard ICE 61508, and the 
concept of model-based risk assessment (MBRA). Security requirements 
are handled as an integrated part of the development and derived from 
enterprize information such as security policies, business goals, law and 
regulation as well as project specific security demands. These are then 
updated and refined in each iteration of the process and finally refined to 
security requirements at a technical level, which can be expressed using 
UMLsec, and analyzed mechanically using the tool-support for UMLsec 
by referring to a precise semantics of the used fragment of UML. 

Keywords: Critical systems development, risk-driven development (RDD), model- 
based risk assessment (MBRA), model-driven development (MDD) 

1. Introduction 

Traditionally, in software development projects the focus is put on 
meeting the end-users’ needs in terms of functionality. This has lead to 
rapidly developed systems with none or little attention to security, and 
many security-critical systems developed in practise turn out to be inse- 
cure. Part of the reason is that most often, secmity is not an integrated 
part of the system development process. While functional requirements 
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are carefully analyzed during system development, non-functional re- 
quirements, such as security requirements, are often considered only af- 
ter the fact. In addition, in practice one has to worry about cost issues 
and try to achieve an adequate level of security under given time limits 
and financial constraints. 

Lifecycle models and development processes are useful means of de- 
scribing the various phases of a development project, from the concep- 
tion of a system to its eventual decommissioning [Lev95]. Several stan- 
dards exist to guide the development of critical systems, e.g. IEC 61508 
[IEC] and the MIL-STD-882B standard [DoD84]. The Australian/New 
Zealand standard AS/NZS 4360:1999 Risk management [43699] is a gen- 
eral standard targeting risk management. The IST-project CORAS 
[COR02] is based on the concept of model based risk assessment (MBRA) 
and has developed an integrated system development and risk manage- 
ment process aiming at security-critical systems. The process is based 
on AS/NZS 4360, Rational Unified Process (RUP) [Kru99], and the Ref- 
erence Model for Open Distributed Processes (RM-ODP) [PutOO]. The 
focus is on handling security issues throughout the development process. 

In our work we have adapted part of the lifecycle model of IEC 61508 
and combined it with the risk management process of AS/NZS4360. 
Further, we base ourselves on the integrated process of CORAS to 
support specification of security requirements at an enterprize level, 
while we use a UML extension for secure systems development, UMLsec 
[Jtir02; Jiir03b], to specify security requirements at a technical level, 
which is then analyzed using tool-support for UMLsec. 

This chapter is organized as following. Section 2 presents related 
work and put the work into context. Section 3 discusses distributed 
system security, while Section 4 provide a brief description of UMLsec. In 
Section 5 we discuss security evaluation of UML diagrams and presents 
the tool supporting security evaluation using UMLsec. Section 6 deals 
with risk-driven development and provide a brief description of IEC 
61508, AS/NZS4360, and the integrated process of CORAS. In Section 7 
we present the MBRA development process for security-critical systems, 
while Section 8 provides an example of how to specify and refine security 
requirements through the development using the MBRA process. In 
Section 9, we summarize the main contributions of the chapter. 

2. Related Work 

There exist a number of specialized risk assessment methodologies 
for the security domain. Within the domain of health care information 
systems the British Government’s Central Computer and Telecommu- 
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nication Agency (CCTA) has developed CRAMM [BD92], CCTA risk 
analysis and management methodology. CRAMM aims at providing a 
structured and consistent approach to computer management of all sys- 
tems. The UK National Health Service considers CRAMM to be the 
standard for risk analysis within systems supporting health care. How- 
ever, CRAMM is intended for risk analysis of computerized systems in 
general. 

Reactive System Design Support (RSDS) [LACOO] and Surety Anal- 
ysis [WCF99] are methodologies integrating modelling and risk anal- 
ysis methods. RSDS is an integrated modelling and risk analysis tool- 
supported methodology developed by King’s College London and B-Core 
UK, ltd, while Surety Analysis is a method developed in Sandia National 
Laboratories, a governmental research organization in the U.S. and aims 
at the modelling and risk analysis of critical and complex systems. These 
approaches do not however put particular focus on specification, alloca- 
tion, and verification of security requirements. 

E.B. Fernandez and J.C. Hawkins present in [FH97] an extension of 
use cases and interaction diagrams to develop distributed system archi- 
tecture requirements. Among other non-functional requirements they 
introduce questions for requirements elaboration, like system commu- 
nication load, fault tolerance, safety, real-time deadlines, and security. 
However, this work is mainly focused on application examples for use 
cases in security-critical systems, not on giving a methodology for their 
development or a concept for their integration with domain models. 
More generally, there are further approaches to a rigorous development 
of critical systems based on UML, including [POOl; GFR02] (and other 
articles in [JCF+02]). 

3. Distributed System Security 

We explain a few important recurring security requirements of dis- 
tributed object-oriented systems which are encapsulated in UMF stereo- 
types and tags in the UMFsec profile by associating formalizations of 
these requirements (referring to the formal semantics) as constraints 
with the stereotypes. The formalizations are obtained following stan- 
dard approaches to formal security analysis. 

Fair exchange When trading goods electronically, the requirement 
fair exchange postulates that the trade is performed in a way that pre- 
vents both parties from cheating. If for example the buyer has to make 
a prepayment, he should be able to prove having made the payment and 
to reclaim the money if that good is subsequently not delivered. 
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Non-repudiation One way of providing fair exchange is by using the 
security requirement of non-repudiation of some action, which means 
that this action cannot subsequently be denied successfully. That is, the 
action is provable, usually wrt. some trusted third party. 

Secure logging For fraud prevention in electronic business transac- 
tions, and in particular to ensure non-repudiation, one often makes use 
of auditing. Here the relevant security requirement represents that the 
auditing data is, at each point during the transaction of the system, con- 
sistent with the actual state of the transaction (to avoid the possibility 
of fraud by interrupting the transaction). 

Guarded access One of the main security mechanisms is access con- 
trol, which ensures that only legitimate parties have access to a security- 
relevant part of the system. Sometimes access control is enforced by 
guards. 

Secure information flow Where trusted parts of a system interact 
with untrusted parts, one has to ensure that there is no indirect leakage 
of sensitive information from a trusted to an untrusted parties. The 
relevant formal security requirement on the flow of information in the 
system is called secure information flow. Trusted parts of a system are 
often marked as “high”, untrusted parts as “low”. 

Secrecy and Integrity Two of the main data security requirements 
are secrecy (or confidentiality; meaning that some information can be 
read only by legitimate parties) and integrity (some information can be 
modified only by legitimate parties). 

Secure communication link Sensitive communication between dif- 
ferent parts of a system needs to be protected. The relevant requirement 
of a secure communication link is here assumed to provide secrecy and 
integrity for the data in transit. 

For UMLsec, we give validation rules that evaluate a model with re- 
spect to listed security requirements. Many security requirements tar- 
get the behavior of a system in interaction with its environment and 
potential adversaries. To verify these requirements, we use the formal 
semantics defined in Section 5. 

4. UMLsec 

We recall the fragment of UMLsec needed in our context. More details 
can be found in [Jtir02; Jiir03b]. UMLsec allows one to express security- 
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Figure 1. Some UMLsec stereotypes 



related information within the diagrams in a UML system specification. 
The extension is given in form of a UML profile using the standard UML 
extension mechanisms. Stereotypes are used together with tags to formu- 
late security requirements and assumptions on the system environment; 
constraints give criteria that determine whether the requirements are 
met by the system design. 

Stereotypes define new types of modelling elements extending the se- 
mantics of existing types or classes in the UML metamodel. Their nota- 
tion consists of the name of the stereotype written in double angle brack- 
ets « », attached to the extended model element. This model element is 
then interpreted according to the meaning ascribed to the stereotype. 

One way of explicitly defining a property is by attaching a tagged value 
to a model element. A tagged value is a name-value pair, where the name 
is referred to as the tag. The corresponding notation is { tag-value } with 
the tag name tag and a corresponding value to be assigned to the tag. 

Another way of adding information to a model element is by attaching 
Constraints to refine its semantics. Stereotypes can be used to attach 
tagged values and constraints as pseudo-attributes of the stereotyped 
model elements. 

In Figure 1 we give the relevant fragment of the list of stereotypes 
from UMLsec, together with their tags and constraints. 

We shortly explain the use of the stereotypes and tags given in Fig- 
ure 1 . More information can be found in [Jiir02; Jiir03b]. 

critical This stereotype labels objects that are critical in some way, 
which is specified in more detail using the corresponding tags. The 
tags are {secrecy} and (integrity). The values of the first two 
are the names of expressions or variables (that is, attributes or mes- 
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sage arguments) of the current object the secrecy (resp. integrity) 
of which is supposed to be protected, 
secure links This stereotype on subsystems containing deployment di- 
agrams is used to ensure that security requirements on the com- 
munication are met by the physical layer, 
secure dependency This stereotype on subsystems containing static 
structure diagrams ensures that the ((call)) and ((send)) depen- 
dencies between objects or subsystems respect the security re- 
quirements on the data that may be communicated across them, 
as given by the tags {secrecy} and {integrity} of the stereotype 
((critical ». 

fair exchange This stereotype of (instances of) subsystems has asso- 
ciated tags start and stop taking names of states as values. The 
associated constraint requires that, whenever a start state in the 
contained activity diagram is reached, then eventually a stop state 
will be reached. 

5. Security evaluation of UML diagrams using 
formal semantics 

For some of the constraints used to define the UMLsec extensions 
we need to refer to a precisely defined semantics of behavioral aspects, 
because verifying whether they hold for a given UML model may be 
mathematically non-trivial. Firstly, the semantics is used to define these 
constraints in a mathematically precise way. Secondly, in ongoing work, 
we are developing mechanical tool support for analyzing UML specifica- 
tions (for example in [Sha03; Men], and a few other student projects). 
For this, a precise definition of the meaning of the specifications is nec- 
essary, and it is useful to formulate this as a formal model for future 
reference before coding it up. For security analysis, the security-relevant 
information from the security-oriented stereotypes is then incorporated. 

Note that because of the complexities of the UML, it would take up 
too much space to recall our formal semantics here completely. Instead, 
we just define precisely and explain the interfaces of the semantics that 
we need here to define the UMLsec profile. More details on the formal 
semantics can be found in [ Jiir03b] . Our formal semantics of a simplified 
fragment of UML using Abstract State Machines (ASMs) includes the 
following kinds of diagrams: 

Class diagrams define the static class structure of the system: classes 
with attributes, operations, and signals and relationships between 
classes. On the instance level, the corresponding diagrams are 
called object diagrams. 
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Statechart diagrams (or state diagrams ) give the dynamic behavior 
of an individual object or component: events may cause a change 
in state or an execution of actions. 

Sequence diagrams describe interaction between objects or system 
components via message exchange. 

Activity diagrams specify the control flow between several compo- 
nents within the system, usually at a higher degree of abstraction 
than statechaits and sequence diagrams. They can be used to put 
objects or components in the context of overall system behavior or 
to explain use cases in more detail. 

Deployment diagrams describe the physical layer on which the sys- 
tem is to be implemented. 

Subsystems (a certain kind of packages ) integrate the information be- 
tween the different kinds of diagrams and between different parts 
of the system specification. 

There is another kind of diagrams, the use case diagrams, which de- 
scribe typical interactions between a user and a computer system. They 
are often used in an informal way for negotiation with a customer before 
a system is designed. We will not use it in the following. Additionally to 
sequence diagrams, there are collaboration diagrams, which present sim- 
ilar information. Also, there are component diagrams, presenting part 
of the information contained in deployment diagrams. 

The used fragment of UML is simplified significantly to keep a formal 
treatment that is necessary for some of the more subtle security require- 
ments feasible and to allow model-checking of UML specifications. Note 
also that in our approach we identify system objects with UML objects, 
which is suitable for our purposes. Also, as with practical all analysis 
methods, also in the real-time setting [Wat02], we are mainly concerned 
with instance-based models. 

Although simplified, our choice of a subset of UML is reasonable for 
our needs, as we have demonstrated in several industrial case-studies 
(some of which are documented in [Jur03b]). 

The formal semantics for subsystems incorporates the formal seman- 
tics of the diagrams contained in a subsystem. Although restricted in 
several ways (see [Jur03b]) any one time an object’s behavior is repre- 
sented by only one diagram in the formal semantics 

■ models actions and internal activities explicitly (rather than treat- 
ing them as atomic given events), in particular the operations and 
the parameters employed in them, 
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• provides passing of messages with their parameters between ob- 
jects or components specified in different diagrams, including a 
dispatching mechanism for events and the handling of actions, and 
thus 

■ allow in principle whole specification documents to be based on a 
formal foundation. 

In particular, we can compose subsystems by including them into other 
subsystems. It prepares the ground for the tool-support based on this 
precise semantics. 

Objects, and more generally system components, can communicate by 
exchanging messages. These consist of the message name, and possibly 
arguments to the message, which will be assumed to be elements of the 
set. Message names may be prefixed with object or subsystem instance 
names. Each object or component may receive messages received in an 
input queue and release messages to an output queue. 

In our model, every object or subsystem instance O has associated 
multi-sets inQuo and outQuo ( event queues). Then our formal semantics 
models sending a message msg = op(expi , . . . , exp n ) £ Events from an 
object or subsystem instance S to an object or subsystem instance R as 
follows: 

(1) S places the message R.msg into its multi-set outQu<j. 

(2) A scheduler distributes the messages from out-queues to the in- 
tended in-queues (while removing the message head); in particular, 
R.msg is removed from outQus and msg added to inQu#. 

(3) R removes msg from its in-queue and processes its content. 

In the case of operation calls, we also need to keep track of the sender 
to allow sending return signals. This way of modelling communication 
allows for a very flexible treatment; for example, we can modify the 
behavior of the scheduler to take account of knowledge on the underlying 
communication layer. 

At the level of single objects, behavior is modelled using statecharts, or 
(in special cases such as protocols) possibly as using sequence diagrams. 
The internal activities contained at states of these statecharts can again 
be defined each as a statechart, or alternatively, they can be defined 
directly using ASMs. 

Using subsystems, one can then define the behavior of a system com- 
ponent C by including the behavior of each of the objects or components 
directly contained in C, and by including an activity diagram that coor- 
dinates the respective activities of the various components and objects. 
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Thus for each object or component C of a given system, our semantics 
defines a function [CIO which 

■ takes a multi-set I of input messages and a component state S and 

■ outputs a set [C|(/,S) of pairs ( 0,T ) where O is a multi-set of 
output messages and T the new component state (it is a set of 
pairs because of the non-determinism that may arise) 

together with an initial state Sq of the component. 

Specifically, the behavioral semantics imo of a statechart diagram 
D models the run-to-completion semantics of UML statecharts. As a 
special case, this gives us the semantics for activity diagrams. Any 
sequence diagram S gives us the behavior I«S.CJ() of each contained 
component C. 

Subsystems group together diagrams describing different parts of a 
system: a system component C given by a subsystem S may contain 
subcomponents Ci,...,C n . The behavioral interpretation [iSJQ of S is 
defined as follows: 

(1) It takes a multi-set of input events. 

(2) The events are distributed from the input multi-set and the link 

queues connecting the subcomponents and given as arguments to 
the functions defining the behavior of the intended recipients in <S. 

(3) The output messages from these functions are distributed to the 

link queues of the li nk s connecting the sender of a message to the 
receiver, or given as the output from mo when the receiver is not 
part of S. 

When performing security analysis, after the last step, the adversary 
model may modify the contents of the link queues in a certain way, 
which is explained in the next section. 

5.1. Security analysis of UML diagrams 

Our modular UML semantics allows a rather natural modelling of po- 
tential adversary behavior. We can model specific types of adversaries 
that can attack different parts of the system in a specified way. For 
example, an attacker of type insider may be able to intercept the com- 
munication links in a company-wide local area network. We model the 
actual behavior of the adversary by defining a class of ASMs that can 
access the communication links of the system in a specified way. To 
evaluate the security of the system with respect to the given type of 
adversary, we consider the joint execution of the system with any ASM 
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in this class. This way of reasoning allows an intuitive formulation of 
many security properties. Since the actual verification is rather indi- 
rect this way, we also give alternative intrinsic ways of defining security 
properties below, which are more manageable, and show that they are 
equivalent to the earlier ones. 

Thus for a security analysis of a given UMLsec subsystem specifi- 
cation S, we need to model potential adversary behavior. We model 
specific types of adversaries that can attack different parts of the system 
in a specified way. For this we assume a function ThreatS/i(s) which 
takes an adversary type A and a stereotype s and returns a subset of 
{delete, read, insert, access} (abstract threats ). These functions arise from 
the specification of the physical layer of the system under consideration 
using deployment diagrams, as explained in Sect. 4. For a link l in a 
deployment diagram in <S, we then define the set threats^ (/) of concrete 
threats to be the smallest set satisfying the following conditions: 

If each node n that l is contained in' carries a stereotype s n with 
access € Threats^ (s n ) then: 

■ If l carries a stereotype s with delete G Threats^ (s) then delete G 
threats^(l). 

■ If l carries a stereotype s with insert G Threats^s) then insert G 

threats^/)- 

■ If l carries a stereotype s with read G ThreatS/i(s) then read G 
threats^ (/). 

■ If l is connected to a node that carries a stereotype t with access G 
Threats,* (t) then {delete, insert, read} C threats’^)- 

The idea is that threats^ (x) specifies the threat scenario against a com- 
ponent or link x in the ASM system A that is associated with an adver- 
sary type A. On the one hand, the threat scenario determines, which 
data the adversary can obtain by accessing components, on the other 
hand, it determines, which actions the adversary is permitted by the 
threat scenario to apply to the concerned links, delete means that the 
adversary may delete the messages in the corresponding link queue, read 
allows him to read the messages in the link queue, and insert allows him 
to insert messages in the link queue. 

Then we model the actual behavior of an adversary of type A as a type 
A adversary machine. This is a state machine which has the following 
data: 

Note that nodes and subsystems may be nested one in another. 
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■ a control state control G State, 

■ a set of current adversary knowledge K C Exp, and 

■ for each possible control state c G State and set of knowledge 
K C Exp, we have 

— a set Delete Ci K which may contain the name of any link l with 

delete G threats^) 

— a set Inserted which may contain any pair (/, E) where l is 
the name of a link with insert G threats^ (/), and E G )C, and 

— a set newState Ci * C State of states. 

The machine is executed from a specified initial state control := 
controlo with a specified initial knowledge K K. o iteratively, where 
each iteration proceeds according to the following steps: 

(1) The contents of all link queues belonging to a link l with read G 
threats^ (/) are added to K. 

(2) The content of any link queue belonging to alink l G Delete con ^ ro | £ 
is mapped to 0, . 

(3) The content of any link queue belonging to a link l is enlarged with 
all expressions E where (l, E ) G lnsert con ^ ro | £. 

(4) The next control state is chosen non-deterministically from the set 

newState controU . 

The set Kq of initial knowledge contains all data values v given in the 
UML specification under consideration for which each node n containing 
V carries a stereotype s n with access G ThreatS/i(s n ). In a given situation, 
Kq may also be specified to contain additional data (for example, public 
encryption keys). 

Note that an adversary A able to remove all values sent over the link 
l (that it, deleter G threats^(i)) may not be able to selectively remove a 
value ewith known meaning from l: For example, the messages sent over 
the Internet within a virtual private network are encrypted. Thus, an 
adversary who is unable to break the encryption may be able to delete 
all messages undiscrimatorily, but not a single message whose meaning 
would be known to him. 

To evaluate the security of the system with respect to the given type 
of adversary, we then define the execution of the subsystem S in presence 
of an adversary of type A to be the function [<S]]/i() defined from mo 




32 



Jan Jurjens, Siv Hilde Houmb 



by applying the modifications from the adversary machine to the link 
queues as a fourth step in the definition of I«SJ() as follows: 

(4) The type A adversary machine is applied to the link queues as de- 
tailed above. 

Thus after each iteration of the system execution, the adversary may 
non-deterministically change the contents of link queues in a way de- 
pending on the level of physical security as described in the deployment 
diagram (see Sect. 4). 

There are results which simplify the analysis of the adversary be- 
havior defined above, which are useful for developing mechanical tool 
support, for example to check whether the security properties secrecy 
and integrity (see below) are provided by a given specification. These 
are beyond the scope of the current paper and can be found in [Jiir03b]. 

One possibility to specify security requirements is to define an ideal- 
ized system model where the required security property evidently holds 
(for example, because all links and components are guaranteed to be se- 
cure by the physical layer specified in the deployment diagram), and to 
prove that the system model under consideration is behaviorally equiv- 
alent to the idealized one, using a notion of behavioral equivalence of 
UML models. This is explained in detail in [Jiir03b]. 

In the following subsection, we consider alternative ways of specifying 
the important security properties secrecy and integrity which do not 
require one to explicitly construct such an idealized system and which 
are used in the remaining parts of this paper. 

5.2. Important security properties 

The formal definition of the two main security properties secrecy 
and integrity considered in this section follow the standard approach 
of [DY83] and are defined in an intuitive way by incorporating the at- 
tacker model. 

Secrecy The formalization of secrecy used in the following relies on 
the idea that a process specification preserves the secrecy of a piece of 
data d if the process never sends out any information from whichd could 
be derived, even in interaction with an adversary. More precisely, d is 
leaked if there is an adversary of the type arising from the given threat 
scenario that does not initially know d and an input sequence to the 
system such that after the execution of the system given the input in 
presence of the adversary, the adversary knows d (where “knowledge”, 
“execution” etc. have to be formalized). Otherwise, d is said to be kept 
secret. 
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Thus we come to the following definition. 

Definition 1 We say that a subsystem S preserves the secrecy of an 
expression E from adversaries of type A ifE never appears in the knowl- 
edge set fC of A during execution of ISIaO- 

This definition is especially convenient to verify if one can give an 
upper bound for the set of knowledge K , which is often possible when 
the security-relevant part of the specification of the system S is given 
as a sequence of command schemata of the form await event e - check 
condition g - output event e ’ (for example when using UML sequence 
diagrams or statecharts for specifying security protocols, see Sect. 4). 

Examples. 

■ The system that sends the expression {m}x :: K 6 Exp over an 
unprotected Internet link does not preserve the secrecy of m or 
K against attackers eavesdropping on the Internet, but the sys- 
tem that sends {m}K (and nothing else) does, assuming that it 
preserves the secrecy of K against attackers eavesdropping on the 
Internet. 

■ The system that receives a key K encrypted with its public key over 
a dedicated communication link and sends back {tn}K over the link 
does not preserve the secrecy of m against attackers eavesdropping 
on and inserting messages on the link, but does so against attackers 
that cannot insert messages on the link. 

Integrity The property integrity can be formalized similarly: If during 
the execution of the considered system, a system variable gets assigned 
a value initially only known to the adversary, then the adversary must 
have caused this variable to contain the value. In that sense the integrity 
of the variable is violated. (Note that with this definition, integrity 
is also viewed as violated if the adversary as an honest participant in 
the interaction is able to change the value, so the definition may have 
to be adapted in certain circumstances; this is, however, typical for 
formalizations of security properties.) Thus we say that a system 
preserves the integrity of a variable V if there is no adversary A such 
that at some point during the execution of the system with A, v has a 
value io that is initially known only to A. 

Definition 2 We say that a subsystem S preserves the integrity of an 
attribute a from adversaries of type A with initial knowledge Kq if during 
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execution of I«SJ/t(), the attribute a never takes on a value appearing in 
/Co but not in the specification S. 

The idea of this definition is that S preserves the integrity of a if no 
adversary can make a take on a value initially only known to him, in in- 
teraction with A. Intuitively, it is the “opposite” of secrecy, in the sense 
that secrecy prevents the flow of information from protected sources to 
untrusted recipients, while integrity prevents the flow of information in 
the other direction. Again, it is a relatively simple definition, which may 
however not prevent implicit flows of information. 

5.3. Tool support 

Security validation in our approach is performed through mechanical 
analysis that validates the fulfilment of the constraints of the security re- 
quirements, as those associated with the stereotypes defined in Section 4. 
A first version has been demonstrated at [Jur03a]. The tool works with 
UML 1.4 models, which can be stored in a XMI 1.2 (XML Metadata In- 
terchange) format by a number of existing UML design tools. To avoid 
processing UML models directly on the XMI level, the MDR (Meta- 
Data Repository, http://mdr.netbeans.org) is used, which allows one to 
operate directly on the UML concept level (as used by e.g. the UML 
CASE tool Poseidon, http://www.gentleware.com). The MDR library 
implements repository for any model described by a modelling language 
compliant to the MOF (Meta Object Facility). 

Figure 2 illustrates the functionality of the tool. The developer cre- 
ates a model and stores it in the UMF 1.4 / XMI 1.2 file format. The 
file is imported by the tool into the internal MDR repository. The tool 
accesses the model through the JMI interfaces generated by the MDR 
library. The checker parses the model and checks the constraints associ- 
ated with the stereotype. The results are delivered as a text report for 
the developer describing found problems, and a modified UMF model, 
where the stereotypes whose constraints are violated are highlighted. 

6. Risk-Driven Development 

In the following, we give a brief introduction to the lifecycle of IEC 
61508, the principle of AS/NZS4360, and the work of CORAS which 
we base our MBRA development approach on. Risk-driven develop- 
ment is risk-driven in that it focusses on assessing risks and proposing 
treatments throughout a set of activities. We assume that functional re- 
quirements are handled as part of the development and focus on security 
requirements and the allocation of security requirements in this section. 
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Figure 2. The UMLsec analysis tool 
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6.1. IEC 61508 

The IEC standard IEC 61508 (Functional safety of electrical/electronic/ 
programmable electronic safety-related systems) [IEC] covers important 
aspects that need to be addressed when electrical, electronic, and pro- 
grammable devices are used in connection with safety functions. The 
strategy of the standard is to derive safety requirements from a hazard 
and risk analysis and to design the system to meet those safety require- 
ments, taking all possible causes of failure into account. The essence is 
that all activities relating to functional safety are managed in a planned 
and methodical way, with each phase having defined inputs and outputs 
[BroOO]. The standard considers all phases in a safety lifecycle, from 
initial concept, through design, implementation, operation and mainte- 
nance to decommissioning. Figure 3 depicts the lifecycle model of IEC 
61508. 

IEC 61508 applies to any safety-related software in which is imple- 
mented as the aforesaid solutions. This includes: (a) software that is 
part of a safety-related system; (b) software that is used to develop a 
safety-related system; and (c) the operating system, system software, 
communication software, human computer interface (HCI) functions, 
utilities, and software engineering tools used with (a) or (b). 

The process consists of the following phases: 

(1) Concept: An understanding of the system and its environment is 
developed. 

(2) Overall scope definition: The boundaries of the system and its 
environment are determined, and the scope of the hazard and risk 
analysis is specified. 

(3) Hazard and risk analysis: Hazards and hazardous events of the 
system, the event sequences leading to the hazardous events, and 
the risks associated with the hazardous events are determined. 

(4) Overall safety requirements: The specification for the overall 
safety requirements is developed in order to achieve the required 
functional safety. 

(5) Safety requirements allocation: The safety functions contained 
in the overall safety requirements specification are allocated to the 
safety-related system, and a safety integrity level is allocated to 
each safety function. 

(6) Overall operation and maintenance planning: A plan is de- 
veloped for operating and maintaining the system, and the required 
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Figure 3. Overall safety lifecycle of IEC 61508 

functional safety is ensured to be maintained during operation and 
maintenance. 

(7) Overall safety validation planning: A plan for the overall 
safety validation of the system is developed. 

(8) Overall installation and commissioning planning: Plans, 
ensuring that the required functional safety are achieved, are de- 
veloped for the installation and commissioning of the system. 

(9) Safety-related systems: The Electrical, Electronic and Pro- 
grammable Electronic Systems (E/E/PES) safety-related system 
is created conforming to the safety requirements specification. 
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(10) Safety-related systems (other technology): Safety-related 
systems based on other technology are created to meet the require- 
ments specified for such systems (outside scope of the standard). 

(11) External risk reduction facilities: External risk reduction fa- 
cilities are created to meet the requirements specified for such fa- 
cilities (outside scope of the standard). 

(12) Overall installation and commissioning: The Electrical, Elec- 
tronic and Programmable Electronic Systems (E/E/PES) safety- 
related system is installed and commissioned. 

(13) Overall safety validation: The Electrical, Electronic and Pro- 
grammable Electronic Systems (E/E/PES) safety-related system 
is validated to meet the overall safety requirements specification. 

(14) Overall operation, maintenance and repair: The system is 
operated, maintained and repaired in order to ensure that the re- 
quired functional safety is maintained. 

(15) Overall modification and retrofit: The functional safety of 
the system is ensured to be appropriate both during and after 
modification and retrofit. 

(16) Decommissioning or disposal: The functional safety of the sys- 
tem is ensured to be appropriate during and after decommissioning 
or disposing of the system. 

6.2. Model-based risk assessment: The CORAS 
approach 

Model-based risk assessment (MBRA) has been a research topic since 
the early 80-ies [KM87 ; G084] and builds on the concept of applying sys- 
tem modelling when specifying and describing the systems to be assessed 
as an integrated part of the risk assessment. The CORAS framework is 
based on the concept of MBRA and employs modelling methodology for 
three main purposes: (1) To describe the target of evaluation at the right 
level of abstraction, (2) As a medium for communication and interaction 
between different groups of stakeholders involved in a risk assessment, 
and (3) To document risk assessment results and the assumptions on 
which these results depend. 

Figure 4 outlines the sub-processes and activities contained in the 
CORAS risk management process, which is a refinement of AS/NZS 
4360:1999. Further information on the CORAS risk management process 
can be found in [HdBLS02]. 
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• Activity 1 .4 : Apprcrvtl 
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Mt-pnceff 3 : Analyse Riels 

• Activity 3.1: Consequence evaluation 

• Activity 3.2: Frequency evalution 

Sub-process 4: Risk Evaluation 

• Activity 4. l:Deteimine level of risk 

• Activity 4.2: Prioritise risks 

• Activity 4.3: Categorise risks 

• Activity 4.4: Deteimine 

intern letianshps among risk themes 

• Activity 4 .5 : Prioritise the re suling 
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Srft-proc ess 5: Risk Treater art 

• Activity 5.1: Identify treatment 
options 

• Activity 5.2: Assess alternative 
treatment approaches 



Figure 4. Sub-processes and activities in the CORAS risk management process 
[HdBLS02] 

The integrated system development and risk management process of 
CORAS is based on the CORAS risk management process, the Refer- 
ence Model - Open Distributed Processing (RM-ODP), and the Rational 
Unified Process (RUP). RUP structures system development according 
to four phases: (1) Inception, (2) Elaboration, (3) Construction, and (4) 
Transition. As illustrated in Figure 5, these two processes are combined 
in order to address security throughout the development. In each itera- 
tion in the development one assesses a particular part of the system or 
the whole system at a particular viewpoint according to RM-ODP. For 
each of the iterations, treatments are evaluated and proposed according 
to a cost-benefit strategy. 

7. MBRA Development Process for 
Security-Critical Systems 

hi system development, one usually distinguishes between three levels 
of abstractions: the requirement specification, the design specification, 
and the implementation. The design specification is thus a refinement 
of the requirement specification, and the implementation is a refinement 
of the design specification. 
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The integrated system development and risk management process 



In the MBRA development process for security-critical systems (see 
Figure 6), we make use of the engineering and technical experience 
gained when developing safety critical systems within the process in- 
dustry. The development process is based on the concept of handling 
safety requirements in IEC 61508 and the idea of using models both to 
document the system and as input to risk management from the CORAS 
integrated risk management and system development process. The pro- 
cess is both stepwise iterative and incremental. For each iteration more 
information is added and increasingly detailed versions of the system are 
constructed through subsequent iterations. 

The first two phases concern the specification of concepts and overall 
scope definition of the system. A system description and a functional 
requirements proposition are the results of these two phases. This in- 
formation is further used as input to the preliminary hazard analysis 
(PHA). By performing a PHA early in the development process, the 
most obvious and conspicuous potential hazards can be identified and 
handled more easily and at a lower cost. Furthermore, the PHA aids 
in the elicitation of security requirements for the system, which is the 
fourth phase in the development process. Based on the security policy 
for the involved organizations, security requirements are specified first 
on the enterprize level and then refined into more technical specifications 
using UMLsec. Phase 4 targets the identification of security threats us- 
ing e.g. Security-HazOp [VogOl]. Security threats are then analyzed in 
terms of finding the frequency of occurrence and potential impacts of 
the threats. Based on the results from risk analysis, risks are evaluated 
and either accepted or not accepted. Unacceptable risks are treated by 
refining or by specifying new security requirements or by introducing 
safeguards before the risk management step is iterated until no unac- 
ceptable risks remain. When the required security level is achieved, the 
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system is implemented and tested. If the implemented version is not 
approved, the process is reiterated from the risk management step. The 
whole process is iterated from phase 1 whenever updating the system 
description or the functional requirements. 




Figure 6. Development process for security-critical systems 



8. Development of a AIBO-Lego Mindstorm 
Prototype Using the Approach 

In this Section, we will illustrate the use and applicability of the risk- 
driven development process for security-critical systems using a AIBO- 
Lego Mindstorm prototype system. The system is used as a medium 
of teaching the effect of handling security and safety as an integrated 
part of development and to test the applicability of techniques and ap- 
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AtEO 




Figure 7. Illustration of the prototype system 



proaches for development of security-critical systems at the Norwegian 
University of Science and Technology (NTNU), Norway. The proto- 
type was developed as part of a Master Thesis at NTNU [Spr02] and 
consists of an prototypical industrial robot and a computerized control 
and monitoring system. The control system is implemented using Lego 
Mindstorm and the monitoring system is implemented using Sony AIBO 
robots as the monitoring system and a PC-controller (portable computer 
with software) representing the control system. AIBO and PC-controller 
communicate using WLAN and TCP/IP as depicted in Figure 7. 

8.1. Concept and overall scope definition 

Concept and overall scope definition constitute the first two phases 
of the process. The main objective of these two phases is to define the 
main objective and purpose of the system. The main objective of the 
Lego-AIBO system is to develop a prototype to investigate the relation- 
ship between security threats and safety consequences in a safety critical 
system that make use of computerized monitoring and control systems. 
However, in this context we will only look into the security aspects of 
the computerized monitoring and control system. The main objective 
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Figure 8. The main components of the AIBO-Lego prototype 



of these two systems is to monitor all access to the safety zone of the 
system and prevent unauthorized access to the zone. 

The AIBO-Lego prototype system consists of three components, the 
monitoring system, the control system, and the production system as 
depicted in Figure 8. The control system receives information from the 
AIBO (monitoring system), processes this information, and sends in- 
structions to the production system based on the information provided 
by the AIBO. The main functionality of the interface between the mon- 
itoring and the control system, represented by the AIBO and the PC- 
controller, is to send and receive information as illustrated in Figure 9. 

8.2. Preliminary hazard analysis (PHA) 

When the purpose and scope of the system has been established, a 
preliminary hazard analysis is performed. In this phase, we use Security- 
HazOp as described in [GWJ01] to identify overall security threats to 
the system. However, due to space restrictions we will only focus on 
security threats related to the communication between the monitoring 




Figure 9. Overview of the main functionality between the AIBO and PC-controller 
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Figure 10. Combination of guidewords used for PHA 



and control system. The reader is referred to Chapter 9 in [S0rO2] for 
more information on the result of the PHA. 

Security-HazOp is an adaptation of the safety analysis method Ha- 
zOp (Hazard and Operability Analysis) for Security-Critical systems. 
Security-HazOp make use of the negation of the security attributes as 
part of the guidewords. Guidewords, in HazOp, is used to guide the 
brainstorming process when identifying security threats. The reader is 
referred to [Lev95] for more information on HazOp. Security-HazOp 
is performed as a brainstorming session using different combinations of 
sentences of the form: 

Pre-Guideword Attribute of Component due to Post-Guideword. 

Figure 10 depicts the combination of guidewords used for PHA. Pre- 
guideword denotes whether the attack is intentional or not, while at- 
tribute is the negation of the security attributes secrecy, integrity, and 
availability. Components denotes the components that are analyzed and 
the post-guideword relate to the thr eat agent who is responsible for the 
attack. 

As input to PHA in a risk-driven development, we use UML diagrams 
describing the main functionality of the system. These diagrams are 
called PHA input diagrams. Figure 11 provide an example of a PHA in- 
put diagram. PHA input diagrams could be any type of UML diagram, 
however, since we are mainly concerned with information flow and be- 
havior in Security-Critical systems, one usually uses one or several of 
the UML behavioral diagrams. Figure 11 depicts a PHA input diagram 
modelled as a UML sequence diagram. The diagram specifies the main 
interface between the control and monitoring system in the AIBO-Lego 
prototype. 

When using UML models as input to PHA or other risk analysis 
methods one goes through each diagram using a set of guidelines. These 
guidelines specify two things: Firstly, the information provided by the 
specific UML diagram that should be used as input, and secondly, how 
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to use the information as input to risk analysis methods. The risk anal- 
ysis methods supported are HazOp (Hazard and Operability analysis), 
FME(C)A (Failure Mode, Effect, and Criticality Analysis, and FTA 
(Fault Three Analysis). Currently, all UML 1.4 diagrams are supported 
by the guidelines (will be updated to support UML 2.0 when finalized). 
As an example we will describe the guideline for using UML sequence 
diagrams as input to HazOp. The reader is referred to [GSD+03] for 
more information on the guidelines. 

HazOp is organized as structured brainstorming using a group of ex- 
perts. The brainstorming meetings consist of a set of experts, a risk 
analysis leader, and a risk analysis secretary. The risk analysis leader 
goes through the set of guidelines as already explained, while the sec- 
retary records the result from the brainstorming during the meeting. 
The result from the brainstorming is recorded in a HazOp table, as 
illustrated in Figure 12. The columns Pre-Guideword, Attribute, and 
Post-Guideword are the same as described in Figure 10. The column ID 
is used to assign a unique id to the threat scenario, while the column 
Asset denotes the information from the UML diagram being analyzed. 
For the guideline for use of UML sequence diagrams as input to HazOp, 
assets are represented as either messages or objects. Generally, an asset 
is something of value to one or more stakeholders and can be anything 
from a particular piece of information to a physical computer or other 
equipment. Assets are typically derived from requirement specifications. 
For more information on how to identify assets, see [GSD + 03]. The col- 
umn Component denotes the part of the system the asset is part of or 
connected to. In the case of the example, we are looking at the commu- 
nication between the A I H O and the PC-Controller. The column Threat 
describes the event that may happen. In the example, the threat is de- 
rived from combining pre-guideword, attribute, asset, and components, 
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| PC-Controller: 
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Figure 11. PH A input diagram as UML sequence diagram 
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for example deliberate manipulation of information on communication 
channel, which gives the threat Incorrect, but valid information. The 
column Threat scenario describes who or what causes the threat to oc- 
cur and the column Unwanted incident describes what happens if the 
threat occurs. In the example death or severe damage to personnel is 
the unwanted incident of the threat that incorrect, but valid information 
is sent on the communication channel because an outsider has altered 
the information. 

We use the UML sequence diagram in Figure 11 as the PHA input 
diagram. PHA input diagrams specify both the structural and behav- 
ioral aspects of a system, and one typically makes use of a set of UML 
diagrams as PHA input diagrams in order to cover both aspects during 
risk analysis. Sequence diagrams describe the behavior of the system. 

Figure 12 provides an example of a PHA with Figure 1 1 as PHA input 
diagram. 
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Figure 12. Example of use of guideline for use of UML sequence diagram as input 
to Security-HazOp 



The main result from PHA is a list of security threats which are 
then used as input to a security requirement specification and alloca- 
tion, which is the next phase in the development process. In this con- 
text, we focus on the security attribute integrity and the security threats 
related to breach of integrity. We look into the communication between 
the AIBO robot and the PC controller where any alteration, being ei- 
ther accidental or intentional, may lead to unauthorized access to the 
system, which might lead to death or serious damage to either unautho- 
rized or authorized personnel. Since we are dealing with a distributed 
object-oriented system we need to make use of secure communication 
link between the monitoring and control system (see Section 3) to ensure 
integrity for information in transit. This can be ensured by encrypting 
the communication link, which is WLAN using TCP/IP as the commu- 
nication protocol, between the AIBO and the PC controller. 
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Figure 13. Security requirement for integrity preservation of the communication 
between AIBO and PC-controller 



The treatment option is transformed into security requirements in the 
next phase of the development process, which is the risk management 
and specification of security requirements phase. 

8.3. Risk management and specification of 
security requirements 

Risk management concerns the following activities: 

■ specifying security requirements addressing security threats from 
PHA, 

■ performing risk identification to reveal unsolved security issues, 
and 

■ analyzing and proposing treatments for the unsolved issues evalu- 
ated as not acceptable. 

In our example, the PHA sketched in the previous section identified 
the need to preserve the integrity of the communication between AIBO 
and the PC-controller. In this phase in the development, we specify 
the security requirements using UMLsec. We make use of the UMLsec 
stereotype ((data security)) and the {integrity} as defined in Section 4 to 
fulfill the demand on preserving integrity of data in transit. Figure 13 
depict the specification of the security requirement integrity preservation 
specifying the communication as ((data security)) and specifying the data 
in need of protection using the {integrity}. 

As defined in Sect. 4 and Sect. 5, for an adversary type A and a stereo- 
type s, we have Threats>i(s) € {delete, read, insert, access}, which are the 
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actions that adversaries are capable of with respect to physical links or 
nodes stereotyped with s. Specifying the security requirement for preser- 
vation of integrity is done using the UMLsec stereotype ((data security)) 
in connection with the {integrity} on the transport layer of the model, 
and the stereotype ((secure links)) on the physical layer. The constraint 
on the communication links between AIBO and PC -controller is that for 
each dependency d with stereotype (( integrity » between components on 
nodes n ^ m, we have a communication link l between n and m with 
stereotype t such that insert Threats^ (s). 

In the next phase of the development process, the security require- 
ments are addressed and allocated through treatment options. This is 
further implemented and validated during the testing and security vali- 
dation phase of the development. 

8.4. Design and implementation 

Design in this context relates to the allocation of security require- 
ments, while implementation relates to the actual implementation of 
the requirements according to the design specification. 

During the PHA and the risk management and specification of secu- 
rity requirements, we identified the need to preserve the integrity of the 
communication between the AIBO, representing the monitoring system, 
and the PC-controller, representing the control system. The communi- 
cation link between the AIBO and the PC-controller is a WLAN connec- 
tion, which is not encrypted by default. We address this requirement by 
making use of encryption according to the encryption protocol depicted 
in Figure 14. 

We thus decide to create a secure channel for the sensitive data that 
has to be sent over the untrusted networks, by making use of cryptogra- 
phy. As usual, we first exchange symmetric session keys for this purpose. 
Let us assume that, for technical reasons, we decide not to use a standard 
and well-examined protocol such as SSL but instead a customized key 
exchange protocol such as the one in Fig. 14. The goal is to exchange 
a secret session key K, using previously exchanged public keys Kc and 
Ks, which is then used to sign the data s which should satisfy integrity 
before transmission. Here {M}k is the encryption of the message M 
with the key K, Sign k{M) is the signature of the message M with K, 
and :: denotes concatenation. 

One can now again use stereotypes to include important security re- 
quirements on the data that is involved. Here, the stereotype 
« critical data )) labels classes containing sensitive data and has the as- 
sociated tags {secrecy}, {integrity}, and {fresh} to denote the respec- 
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tive security requirements on the data. The constraint associated with 
« data security )> then requires that these requirements are met relative 
to the given adversary model. We assume that the standard adversary 
is not able to break the encryption used in the protocol, but can ex- 
ploit any design flaws that may exist in the protocol, for example by 
attempting so-called “man-in-the-middle” attacks (this is made precise 
for a universal adversary model in Sect. 5.1). Technically, the constraint 
then enforces that there are no successful attacks of that kind. Note that 
it is highly non-trivial to see whether the constraint holds for a given 
protocol. However, using well-established concepts from formal methods 
applied to computer security in the context of UMLsec, it is possible to 
verify this automatically. 

We refer to [Spr02] for further details on these two phases in the 
development process. 

8.5. Testing and security validation 

Testing and security validation target both the testing of functional 
requirements and the validation of the fulfillment of security require- 
ment. In this context, we refer to other sources for testing strategies 
such as [PatOO] and will only discuss and illustrate how to perform the 
security validation. 

Security requirements are specified using UMLsec and the security 
validation is performed using the tool support for UMLsec as described 
in Section 5.3. 

9. Conclusion 

Traditionally, software development processes do not offer particular 
support for handling security requirements. In most cases, security issues 
are only considered after the fact, which is both costly and resource 
demanding. Security should therefore be handled as an integrated part 
of system development. The focus is on providing an adequate level of 
security given resource bounds on time and money. 

We have presented a MBRA development process for security-critical 
systems based on the safety standard IEC 61508 and integrated sys- 
tem development and risk management process of CORAS. The process 
consists of seven phases: 

(1) Concept, 

(2) Scope definition, 

(3) Preliminary Hazard Analysis, 
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(4) Risk Management, 

(5) Design, 

(6) Implementation, and 

(7) Testing and security validation. 

The main aim is to use models not only to specify and document the 
system, but also as input into the PHA and risk management. 

In our approach, models are used for five purposes: 

(1) precise specification of non-functional requirements, 

(2) as a medium to communicate non-functional requirements, 

(3) to describe the target of assessment, 

(4) as a medium to communicate risk assessment results, and 

(5) to document risk assessment results. 

Furthermore, models are also used for security validation using tool sup- 
port for UMLsec. The main purpose of this is to validate that the im- 
plementation fulfills the security requirements. 

The process is illustrated using an AIBO-Lego Mindstorm prototype 
system, where the focus is on the computerized part of the system and 
how security threats may affect the safety of the system. However, the 
process is designed for security-critical system in general and target both 
small web applications as well as large scale production systems. 
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Abstract: Software portability is often cited as desirable, but rarely receives systematic 

attention in the software development process. With the growing diversity of 
computing platforms, it is increasingly likely that software of all types may 
need to migrate to a variety of environments and platforms over its lifetime. 
This tutorial is intended to show the reader how to design portability into 
software projects, and how to port software when required. 



Key words: software engineering; software portability 



1. INTRODUCTION 

Most software developers agree that portability is a desirable attribute for 
their software projects. The useful life of an application, for example, is 
likely to be extended, and its user base increased, if it can be migrated to 
various platforms over its lifetime. In spite of the recognized importance of 
portability, there is little guidance for the systematic inclusion of portability 
considerations in the development process. 

There is a fairly large body of literature on aspects of portability. A 
comprehensive bibliography is provided by Deshpande (1997). However, 
most of this literature is based on anecdotes and case studies (e.g. Blackham 
(1988), Ross (1994)). A few seminal books and papers on portability 
appeared in the 1970s (e.g. Brown (1977), Poole (1975), Tanenbaum 
(1978)). Several books on software portability were published in the 1980s 
(Wallis (1982), Dahlstrand (1984), Henderson (1988), LeCarme (1989)). 
None of these publications provide a systematic, up-to-date presentation of 
portability techniques for present-day software. This tutorial offers one 
approach to reducing this void. 
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Well-known strategies for achieving portability include use of standard 
languages, system interface standards, portable libraries and compilers, etc. 
These tools are important, but they are not a substitute for a consistent 
portability strategy during the development process. The problems are 
compounded considerably by the more demanding requirements of much 
present-day software, including timing constraints, distribution, and 
sophisticated (or miniaturized) user interfaces. 

This tutorial introduces a broad framework of portability issues, but 
concentrates on practical techniques for bringing portability considerations 
to the software development process. The presentation is addressed both to 
individual software designers and to those participating in an organized 
development process. 

It is not possible in a paper of this length to provide a detailed and 
thorough treatment of all of the issues and approaches for software 
portability. We will offer an introduction designed to increase awareness of 
the issues to be considered. 



2. THE WHAT AND WHY OF PORTABILITY 

In this section we will examine what we mean by portability, consider 
some related concepts, and discuss why porting may be desirable. 

2.1 What is Portability? 

The concept of software portability has different meanings to different 
people. To some, software is portable only if the executable files can be run 
on a new platform without change. Others may feel that a significant 
amount of restructuring at the source level is still consistent with portability. 

The definition we will use for this study leans toward the latter view and 
includes seven key concepts. This definition originally appealed in Mooney 
( 1990 ): 

A software unit is portable (exhibits portability) across a class of 
environments to the degree that the cost to transport and adapt it to a 
new environment in the class is less than the cost of redevelopment. 

Let’s examine the key concepts in this definition. 

• Software Unit. Although we will often discuss portability in the context 
of traditional applications, most ideas may also apply to other types of 
software units, ranging from components to large software systems. 
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• Environment. This term refers to the complete collection of external 
elements with which a software unit interacts. These may include other 
software, operating systems, hardware, remote systems, documents, and 
people. The term is more general than platform, which usually refers 
only to the operating system and computer hardware. 

• Class of Environments. We use this term to emphasize that we seek 
portability not only to a set of specific environments, which are known a 
priori, but to all environments meeting some criteria, even those not yet 
developed. 

• Degree of Portability. Portability is not a binary attribute. We consider 
that each software unit has a quantifiable degree of portability to a 
particular environment or class of environments, based on the cost of 
porting. Note that the degree of portability is not an absolute; it has 
meaning only with respect to a specific environment or class. 

• Costs and Benefits. There are both costs and benefits associated with 
developing software in a portable manner. These costs and benefits take 
a variety of forms. 

• Phases of Porting. We distinguish two major phases of the porting 
process: transportation and adaptation. Adaptation includes most of the 
modifications that need to be made to the original software, including 
automated retranslation. Transportation refers to the physical movement 
of the software and associated artifacts, but also includes some low level 
issues of data representation. 

• Porting iw. Redevelopment. The alternative to porting software to a new 
environment is redeveloping it based on the original specifications. We 
need to compare these two approaches to determine which is more 
desirable. Porting is not always a good idea! 

Note that while we concentrate on the porting of software, there may be 
other elements for which portability should be considered. These include 
related software such as libraries and tools, as well as data, documentation, 
and human experience. 

2.2 Why should we Port? 

Before we make the effort to make software portable, it is reasonable to 
ask why this may be a good idea. Here are a few possible reasons: 

• There are many hardware and software platforms; it is not only a 
Windows world. 

• Users who move to different environments want familiar software. 
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• We want easier migration to new system versions and to totally new 
environments. 

• Developers want to spend more time on new development and less on 
redevelopment. 

• More users for the same product means lower software costs. 

The advantages of portability may appear differently to those having 

different roles. Here are some of the key stakeholders in software 

development and their possible interests in portability: 

• Users may benefit from portable software because it should be cheaper, 
and should work in a wider range of environments. 

• Developers should benefit from portable software because 
implementations in multiple environments are often desired over the 
lifetime of a successful product, and these should be easier to develop 
and easier to maintain. 

• Vendors should find software portability desirable because ported 
implementations of the same product for multiple environments should 
be easier to support, and should increase customer loyalty. 

• Managers should find advantages in portable software since it is likely to 
lead to reduced maintenance costs and increased product lifetime, and to 
simplify product enhancement when multiple implementations exist. 
However, managers must be convinced that the cost to get the first 
implementation out the door may not be the only cost that matters! 

2.3 Why shouldn’t we Port? 

Portability is not desirable in all situations. Here are some reasons we 

may not want to invest in portability: 

• Sometimes even a small extra cost or delay in getting the product out the 
door is not considered tolerable. 

• Sometimes even a small reduction in performance or storage efficiency 
cannot be accepted. 

• Sometimes a software unit is so tightly bound to a specialized 
environment that a change is extremely unlikely. 

• Sometimes source files or documentation are unavailable. This may be 
because developers or vendors are protective of intellectual property 
rights. 
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2.4 Levels of Porting 

A software unit goes through multiple representations, generally moving 
from high to low level, between its initial creation and actual execution. 
Each of these representations may be considered for adaptation, giving rise 
to multiple levels of porting: 

• Source Portability. This is the most common level; the software is 
adapted in its source-level, human-readable form, then recompiled for the 
new target environment. 

• Binary Portability. This term refers to porting software directly in its 
executable form. Usually little adaptation is possible. This is the most 
convenient situation, but possible only for very si mi lar environments. 

• Intermediate-Level Portability. In some cases it may be possible to adapt 
and port a software representation that falls between source and binary. 

2.5 Portability Myths 

The portability problem is often affected by the “silver bullet” syndrome. 
A wide variety of innovations have all promised to provide universal 
portability. These include: 

• Standard languages (e.g., FORTRAN, COBOL, Ada, C, C++, Java) 

• Universal operating systems (e.g., Unix, MS-DOS, Windows, JavaOS) 

• Universal platforms (e.g., IBM-PC, SPARC, JavaVM, .NET) 

• Open systems and POSIX 

• OOP and distributed object models (e.g., OLE, CORBA) 

• Software patterns, architectures, and UML 

• The World Wide Web 

All of these have helped, but none have provided a complete solution. 
We will examine both the value and the limitations of these technologies. 



3. INTERFACES AND MODELS 

A software unit interacts with its environment through a collection of 
interfaces. If we can make these interfaces appear the same across a range 
of environments, much of the problem of portability has been solved. The 
first step in controlling these interfaces is to identify and understand them. 
We will make use of interface models to establish a framework for 
discussion. 
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A number of interface models have been defined and used by industry 
and governments. Examples include the U.S. Department of Defense 
Technical Reference Model, The Open Group Architectural Framework, and 
the CTRON model. Most of these are quite complex, identifying a large 
number of interface types classified along multiple dimensions. 

A very simple but useful model was developed as part of the POSIX 
effort to create a framework for open systems. Open systems are defined as 
environments that are largely based on non-proprietary industry standards, 
and so are more consistent with portability goals. The model defined by the 
POSIX committees is the Open Systems Environment Reference Model 
(OSE/RM) (ISO/IEC 1996). 

This model is illustrated in Figure 1 . It defines two distinct interfaces: 
the interface between an application and a platform (the Application 
Program Interface, or API) and the interface between a platform and the 
external environment (the External Environment Interface, or EEI). 
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Figure 1. The POSIX Open Systems Environment Reference Model 

The OSE/RM does not provide much detail by itself, but it forms the 
foundation for many of the other models. 
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The interface model that will form the basis for our study is the Static 
Interface Model (SIM), originally proposed by the author (Mooney, 1990). 
This model assumes that the software to be ported is an application program, 
although other software units would lead to a similar form. The application 
is in the upper left corner, and the interfaces with which it interacts are 
shown below and to the right. 

The model identifies three direct interfaces with which the application is 
assumed to interact through no (significant) intermediary. These are: 

• The Processor/Memory Interface, also called the Architecture Interface, 
which handles all operations at the machine instruction level. 

• The Operating System Interface, responsible for all services provided to 
an application by the operating system. 

• The Library Interface, which represents all services provided by external 
libraries. 




Figure 2. The Static Interface Model 



The model further identifies a number of indirect interfaces, which are 
composed of multiple direct interfaces connecting other entities. For 
example, the user interface involves a chain of interfaces between the 
application, the operating system, the terminal device, and the user. 
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Note that the model only identifies interfaces between the application and 
other entities. Also note that the Operating System Interface could, strictly 
speaking, be called indirect, since a library is usually involved. However, it 
is useful to treat this as a direct case. 

The value of these models lies in using them to identify and focus on 
specific interfaces that may be amenable to a particular' portability strategy. 
The SIM provides a useful level of detail for this purpose. As we will see in 
Section 5, we can identify distinct and useful strategies for each of the direct 
interfaces of this model. 

The interface models considered here are static models; they represent a 
snapshot of the state of a computing system, typically during execution. 
Dynamic models are also used to identify the various representations which 
may exist for a software unit (and its interfaces) and the translation steps that 
occur between representations. In the usual case, software ready for porting 
to a specific environment exists in the form of a source program in a 
common “high-level” programming language. This program may originally 
have been derived from still higher-level representations. This source 
program is translated into one or more intermediate forms, and a final 
translation produces the executable form to be loaded into memory and 
executed. Each of these representations offers a different opportunity to 
bridge interface differences through manual or automated modification. 

Other models that may be useful include models of the porting process 
itself. These are beyond the scope of this paper. 



4. THE ROLE OF STANDARDS 

A standard is a commonly accepted specification for a procedure or for 
required characteristics of an object. It is well known that standards can play 
a crucial role in achieving portability. If a standard can be followed for a 
particular interface, chances are greatly increased that different environments 
can be made to look the same. However, standards evolve slowly, so many 
important interface types are not standardized. Also, standards have many 
limitations, and only a small number of the vast array of standards in 
existence can be considered a reliable solution to the problem. 

Here we will briefly discuss some issues in the use of standards to help 
solve the software portability problem. We are interested in software 
interface standards: those that define an interface between multiple entities, 
at least one of which is software. A very large collection of computer- 
related standards fits this description. 
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A software interface standard will aid in the development of portable 
software if it: 

1. provides a clear, complete and unambiguous specification for a 
significant interface or subset, in a form suitable for the software to be 
developed; 

2. Has implementations that are widely available or may be easily 
developed for likely target environments. 

Unfortunately, many standards fall short of these requirements. They 
may be expressed in an obscure notation that is hard to understand, or in 
natural language that is inherently imprecise. There are often many 
contradictions and omissions. A standard will only become widely 
implemented if there is already a high demand for it; often a major barrier is 
the cost of the standard itself. 

Standards come into being in three principal ways, each with their own 
advantages and disadvantages. 

• Formal standards are developed over an extended time by widely 
recognized standards organizations such as ISO. They represent a broad 
and clear consensus, but they may take many years to develop, and are 
often obsolete by the time they are approved. Some very successful 
formal standards include the ASCII standard for character codes, the 
IEEE binary floating point standard, the POSIX standard for the UNIX 
API, and the C language standard. 

• Defacto standards are specifications developed by a single organization 
and followed by others because of that organization's dominance. These 
are popular by definition but subject to unpredictable change, often for 
limited commercial interests. Examples include the IBM-PC 
architecture, the VT-100 terminal model, and the Java language. 

• Consortium standards are a more recent compromise. They are 
developed in an open but accelerated process by a reasonably broad- 
based group, often formed for the specific purpose of maintaining certain 
types of standards. Example standards in this class include Unicode, 
OpenGL, and the Single Unix Specification. 

Standards will play a critical role in the strategies to be discussed, but 
they are only a starting point. 
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5. STRATEGIES FOR PORTABILITY 

If software is to be made portable, it must be designed to minimize the 
effort required to adapt it to new environments. However, despite good 
portable design, some adaptation will usually be necessary. This section is 
concerned with identifying strategies that may be used during development 
to reduce the anticipated level of adaptation, and during porting to carry out 
the required adaptation most effectively. 

5.1 Three Key Principles 

There are many approaches and techniques for achieving greater 
portability for a given software unit. These techniques may be effectively 
guided by three key principles. 

5.1.1 Control the Interfaces 

As noted in previous sections, the major problems of portability can be 
overcome by establishing a common set of interfaces between a software 
entity and all elements of its environment. This set may include many 
different interfaces of various types and levels. 

These interfaces may take many forms: a programming language, an API 
for system services, a set of control codes for an output device. 

Commonality of the interfaces requires that each interface be made to 
look the same from the viewpoint of the software being developed, in spite 
of variations in the components on the other side. This goal may be 
achieved by many different strategies. Some of these strategies may 
successfully establish a common interface during initial development, while 
others will require further effort during porting. 

5.1.2 Isolate Dependencies 

In a realistic software project there will be elements that must be 
dependent on their environment, because variations are too great or critical 
to be hidden by a single common interface. These elements must be 
confined to a small portion of the software, since this is the portion that may 
require modification during porting. 

For example, software that manages memory dynamically in a 
speciahzed way may be dependent on the underlying memory model of the 
architecture or operating system; graphics algorithms may depend on the 
output models supported; high-performance parallel algorithms may need to 
vary depending on the architectural class of the machine. 
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Notice that this is also an interface issue, since the dependent portions of 
the software need to be isolated behind a limited set of interfaces. 

5.1.3 Think Portable 

This final principle is simply an admonition to be conscious of the 
portability goal during all design decisions and development activities. 
Many portability problems arise not because there was no way to avoid 
them, but because portability wasn’t considered when the choice was made. 

5.2 Classifying the Strategies 

The strategies to be studied are concerned with controlling particular 
interfaces. They can be identified and classified by considering the various 
interface models of Section 2. Static models such as the SIM or the 
OSE/RM allow us to identify the principal interfaces with which a typical 
application interacts. We have seen that the primary low-level interfaces can 
be classified as architecture interfaces (including processor, memory, and 
direct I/O), operating system interfaces (including APIs), and library 
interfaces (including support packages). 

We are most interested in achieving commonality for these low-level 
interfaces. These interfaces in turn mediate access to higher-level interfaces 
such as the user interface, file systems, network resources, and numerous 
domain-specific abstractions. Controlling these interfaces can be viewed as 
special cases of controlling the underlying interfaces to the architecture, 
operating system, and libraries. 

The first and most essential strategy for portable software development is 
the use of a suitable programming language. Portable programming in an 
appropriate language will generally provide a common model for most (but 
not all) of the elements of each of the three main interface classes. The 
remaining elements must be dealt with by considering the interfaces more 
directly. 

There are thus four main classes of strategies that are most important to 
consider: 

1. Language-based strategies 

2. Library strategies 

3. Operating system strategies 

4. Architecture strategies 

Regardless of the specific interface or representation we are dealing with, 
all strategies for achieving portability at that interface can be grouped into 
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three main types. We examine these types in the next subsection. We will 
then discuss strategies of each type that apply to each of the four classes. 

5.3 Three Types of Strategies 

The object of an interface strategy is to enable a software unit at one side 
of the interface to adapt to multiple environments at the other side. If we can 
arrange for the software unit to have the same predictable view of the 
interface for all environments, the problem has been solved. This can occur 
if there is a well-known common form that most environments will follow, 
or if the element on the other side of the interface can be kept the same in 
each environment. 

If there is no common model known when the software unit is designed, 
then interface differences are likely to exist when porting is to be done. In 
this case, a translation may be possible to avoid more extensive 
modifications to the software. 

These considerations lead us to identify three fundamental types of 
strategies. All of the more specific strategies we will consider can be placed 
into one (or occasionally more) of these types. 

5.3.1 Standardize the Interface 

If an existing standard can be identified which meets the needs of the 
software unit and is likely to be supported by most target environments, the 
software can be designed to follow this standard. For example, if most 
environments provide a C compiler, which adequately implements the C 
standard, it may be advantageous to write our programs in standard C. 

This strategy must be followed in the initial development of the 
software. It relies on the expectation that the standard will truly be 
supported in (nearly) identical form in the target environments. Figure 5 
depicts the general form of this strategy. 

5.3.2 Port the Other Side 

If the component on the other side of the interface can be ported or 
reimplemented in each target environment, it will consistently present the 
same interface. For example, porting a library of scientific subroutines 
ensures that they will be available consistently in the same form. 

This strategy may be chosen during initial development, or selected for 
a specific implementation. Note that in this case we are actually “extending 
the boundaries” of the ported software, and trading some interfaces for 
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others. The interfaces between the extra ported components and their 
environment which is not ported, must be handled by other strategies. 

5.3.3 Translate the Interface 

If the interfaces do not match, elements on one side may be converted 
into the equivalent elements on the other. This may be done by an overall 
translation process when porting, or by providing extra software that 
interprets one interface in terms of the other during execution. 

An example of the first variation is the usual compiling process. The 
common representation for the architecture interface of a program (in the 
source language) is translated to the specific architecture of the target. The 
second variation is illustrated by a library that converts one set of graphics 
functions to a different set provided in the target environment. 

This strategy may be planned during development but must be carried 
out in the context of a specific implementation. 

There is one alternative to all these approaches; that is to redesign the 
software to fit the interface of the target environment. This is not a 
portability strategy, but an alternative to porting. Sometimes this is the best 
alternative, and we must know how to make a choice. This issue will be 
discussed later. 

We now are prepared for a look at the various strategies associated with 
each of the main classes: language, library, operating system, and 
architecture. 

5.4 Language Based Strategies 

Effective approaches to portable design start with the choice and 
disciplined use of a suitable programming language. If the language allows 
a single expression of a program to be understood identically in all target 
environments, then portability will be achieved. 

In practice, it is very often possible to express many of a program's 
requirements in a common language, but not all of them. If the language 
includes no representation for certain concepts, they must be handled by 
other strategy classes. 

Sometimes the language in which the program is currently expressed is 
not supported for the target environment. In this case it becomes necessary 
to translate the software from one language to another. 

The source language representation of a software unit is the most 
convenient starting point for both manual adaptation (e.g. editing) and 
automated adaptation (e.g. compiling) to prepare it for use in a given target 
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environment. Therefore language-based strategies are the single most 
essential class in our collection. 

Language strategies for portability may be classified according to the 
three types identified in the previous section: standardize, port, translate. 

5.4.1 Standard Languages 

Programming languages were among the first types of computer-related 
specifications to be formally standardized. Today formal standards exist for 
over a dozen popular general-purpose languages, including FORTRAN, 
COBOL, Ada, Pascal, C, and C++ (note that standardization for Java is not 
yet achieved). 

Writing a program in a standard language is an essential step in achieving 
portability. Flowever, it is only a starting point. The language must be one 
that is actually available in most expected target environments. No standard 
is clear, complete and unambiguous in every detail, so the programmer must 
follow a discipline (think portable!) that avoids use of language features 
which may have differing interpretations. No language covers all of the 
facilities and resources that particular programs may require, so portability in 
some areas must be achieved by other means. 

Effective use of standard languages is crucial to achieving portability. 
Each of the most widely-used languages presents a somewhat different set of 
opportunities and problems for effective portable programming. For 
example, C does not fully define the range of integers; many Java features 
continue to vary as the language evolves. Standard language strategies, and 
the issues raised by specific languages, are often the subject of books and are 
beyond the scope of this paper. 

5.4.2 Porting the Compiler 

One of the potential problems of the use of standard languages is the fact 
that different compilers may use different interpretations in areas where the 
standard is not completely clear. If the same compiler is used for each target 
environment, then its interpretation of a software unit will not vary, even if it 
is non-standard! 

To exploit this situation, we may choose to write a program for a specific 
compiler, then “port the compiler” to each new environment. Porting the 
compiler, of course, may be a daunting task, but it needs to be done only 
once to make all software for that compiler usable on the new target. Thus 
the payoff may be great, and if we are lucky, someone has already done it for 
us. 
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It is actually misleading to speak of porting the compiler; the essential 
requirement is to retarget the compiler. The compiler’s “back end” must be 
modified to generate code for the new machine. Many compilers are 
designed to make this type of adaptation relatively easy. The retargeted 
compiler may also be ported to the new environment, but it does not actually 
matter on which system it runs. 

In some cases the compiler is a commercial product, not designed to 
allow adaptation by its users. In this case we must rely on the vendor to do 
the retargeting, or else this strategy is unavailable. Many open source 
compilers, such as the GNU compilers, are designed for easy retargeting. 

5.4.3 Language Translation 

A compiler translates software from a human-oriented language to a 
language suitable for execution by machine. It is also possible to translate 
programs from one human-oriented language to another. If we are faced 
with a program written in a language for which we have no compiler for the 
target, and no prospect of obtaining one, then “source-to-source translation” 
may be the best porting strategy available. 

Translating software from Pascal to FORTRAN or C to Java is 
considerably more challenging than compiling, though not as difficult as 
natural language translation. Several tools are available which perform 
reasonable translations among selected languages. Usually these tools can 
do only an imperfect job; translation must be regarded as a semi-automated 
process, in which a significant amount of manual effort may be required. 

Translation can also be used as a development strategy, when compiler 
variations are anticipated. Software may be originally written in a “higher- 
level” language that can be translated into multiple languages or, more 
likely, language dialects, using a preprocessor. This is more likely to be a 
strategy that can be fully automated. 

5.5 Library Strategies 

No programming language directly defines all of the resources and 
facilities required by a realistic program. Facilities that are neither defined 
within the language nor implemented by the program itself must be accessed 
explicitly through the environment. This access may take the form of 
procedure or function calls, method invocations, messages, program- 
generated statements or commands, etc. Whatever the mechanism, the aim is 
to obtain services or information from software and physical resources 
available in the environment. 
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These resources are organized into packages, collections, or subsystems 
that we may view uniformly as libraries. Examples may include language- 
based libraries such as C standard functions, scientific computation libraries, 
graphic libraries, domain-specific classes and templates, mail server 
processes, network interfaces, or database management systems. 

These libraries provide a class of interfaces, and programs that rely on 
them will be most portable if they are able to access these facilities in a 
common form. When this is not possible, adaptation will be required. 

We must assume, of course, that the target systems are capable of 
supporting the services and facilities to which the libraries provide access. 
No portability strategy can enable a program that plays music to run on a 
system that has no hardware support for sound! 

Once again we can identify three classes of library strategies according to 
our three principal types: standardize, port, translate. We will overview 
these strategies in the following subsections 

5.5.1 Standard Libraries 

Many types of library facilities are defined by formal or defacto 
standards. This group is led by libraries that are incorporated into specific 
language standards, such as the C standard function library, Ada standard 
packages, standard procedures and functions of Pascal, standard templates 
for C++, etc. Software written in these languages should use the standard 
facilities as far as possible, taking care to distinguish what is actually 
standard and what has been added by a particular language implementation. 

Additional standard library facilities are not bound to a specific language 
but are widely implemented in many environments. This is especially likely 
for libraries providing services of broad usefulness. Some examples here 
include GKS libraries for low-level graphics functions, MPI for message 
passing, CORBA for distributed object access, or SQL for database access. 
Portable software may rely on such libraries if they are expected to be 
widely available, but must make use of an alternate strategy when they are 
not. 

If the absence of a library supporting an important standard is a major 
drawback for the target environment, it may be worthwhile to consider 
implementing such a library. This is likely to be a major effort but could 
significantly improve the target environment as well as aiding the immediate 
porting project. 
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5.5.2 Portable Libraries 

Instead of relying on the wide availability of library implementations 
which conform to a common standard, we may rely on a single 
implementation, not necessarily standardized (although it creates a de facto 
standard), which is or can be ported to a wide variety of environments. 

A few examples include the mathematical libraries of the Numerical 
Algorithms Group (NAG) and the linear algebra library LINPACK for high- 
performance computing. 

If the library is non-proprietary and its source code is available, then we 
may rely on porting the library ourselves when faced with an environment 
which does not support it. Again, this may be a large task, perhaps larger 
than porting the rest of the software, but the benefits may apply to many 
projects. If the library is proprietary, the only hope is to appeal to the 
vendor. 

5.5.3 Interface Translation 

In some cases the target environment will provide a library with the 
necessary functionality, but not in the expected form. In this case an 
additional library must be created to “bridge” the difference. This library 
becomes a part of the porting effort, and must present the required services 
in the form expected by the program, using the facilities provided by the 
native library. The effort to create such a bridge library can range from 
minimal to extensive, depending on the extent of the difference between the 
two interfaces. Once created it may provide benefits for multiple projects, as 
though the library itself had been ported. 

5.6 Operating System Strategies 

Many of the services which a program accesses from its environment are 
provided or mediated by the operating system (OS). As can be seen from the 
Static Interface Model, the OS may directly provide services such as process 
management, memory management, file access, timing services, security 
services, etc. It is also a key mediator in the user interface, and in interfaces 
to networks and I/O devices. 

Some of these services, such as simple file access, may be defined 
directly by the programming language. Others may be defined by standard 
libraries such as the C library. However, a variety of services may be 
obtainable only by direct request to the OS. This is especially true of many 
newly important services such as thread management, multimedia, or 
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Internet access for which higher-level standards are still evolving. The OS 
interface is thus a key issue for portability in a large number of programs. 

Since portability is most commonly considered as a proper expectation of 
application programs (more than specialized system programs), the operating 
system interface is referred to as the Application Program Interface, or API. 
It would perhaps be more accurate to speak of the “OSAPI”, identifying the 
entity on both sides of the interface, but this term has not caught on. 

Most OSs support a number of programming languages and must make 
their services available in a uniform language-independent form. This 
creates the need for two representations of the API: a language-independent 
form, as presented by the OS, and a representation in terms of the particular 
programming language used, called a language binding. A small library is 
needed to provide services in the form specified by the language binding and 
convert them to the form provided by the underlying operating system. In 
this discussion we will ignore this extra layer and focus our strategics on the 
language-independent API. 

As before, we can consider three main classes of strategics: standardize, 
port, or translate. 

5.6.1 Standard APIs 

As recently as the early 1980s there was no such thing as a “standard” 
API. Each specific OS presented its services in its own way. Even when the 
services were equivalent, there was no effort to represent them by a common 
model. 

A great deal of variation often existed (and still does) even within 
versions of the “same” OS. Many subtle differences in UNIX APIs have 
made portability a problem even from one UNIX to another. This created a 
strong motivation for the POSIX project. Similar problems across versions 
of proprietary OSs led vendors to create their own internal standards. 

Today there are a variety of established and developing standards for 
APIs, both formal and defacto. Important examples include the POSIX 
system interface for “UNIX-like” environments, and the Win-32 API for 
Microsoft Windows systems. 

Unfortunately, there are few standard APIs which span distinctly 
different types of operating systems, such as UNIX and Windows and z/OS 
and Palm OS, etc. In some cases standard APIs can be implemented (less 
naturally and efficiently, of course) by libraries on top of a different type of 
OS. The POSIX API, in particular, has been implemented for a wide variety 
of environments which are not actually similar to UNIX. 
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If the set of target systems anticipated for porting, or a significant subset, 
is covered by a standard API, then that standard should probably be 
followed. If not, we must continue with other strategies. 

5.6.2 Porting the Operating System 

The idea of porting an operating system may seem completely 
unreasonable. The purpose of the OS is to manage resources, including 
hardware resources, so its design must be tied closely to the machine 
architecture. Because of the need for efficiency and compactness, many OSs 
have been written in assembly language. The OS is designed from the 
ground up to suit a particular machine; moving it to another just doesn’t 
make sense. 

In spite of this, a number of operating systems have been successfully 
ported, and some have been designed to be portable. A few early research 
systems in this category include OS/6, MUSS, and THOTH. These systems 
were designed in ways that allowed hardware access but remained somewhat 
architecture-independent, often using the generic architecture strategy 
discussed below. They were programmed in medium-level “system 
implementation languages” such as BCPL. As a result, they were 
successfully ported to multiple hardware environments. 

The quintessential example of a portable OS today is UNIX. UNIX has 
been ported to, or reimplemented for, almost every known hardware 
environment suited for general-purpose computing. UNIX and all of its 
related programs are written in C, so porting is greatly facilitated by the 
creation of a C compiler. The various implementations represent many 
slight variations, but they all share a common core of UNIX concepts. 

Porting a compiler is a project that is likely to have high costs but also 
high benefits. This is true to a much greater degree for OS porting. The 
effort required may be enormous, but the result is the ability to support a 
whole new collection of software in the new environment. 

Unfortunately, though, most environments can only run one OS at a time 
for all users. Porting a new OS means removing the old one. This will have 
a very strong impact on users; we do not recommend that you change the OS 
on a system that is used by many people unless there is broad agreement that 
this is a good idea! 

5.6.3 Interface Translation 

If it is not possible to ensure that the API for which the program is 
designed will be supported in the target environment, then a translation 
library may be necessary. This library can range from trivial to highly 
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complex, depending on the differences in the resource models expected by 
the program and those supported on the target platform. For example, the 
Windows interface is implemented on UNIX systems, and POSIX libraries 
are available for environments as diverse as Open VMS and MVS. 

5.7 Architecture Strategies 

The first and most fundamental of the three main direct interfaces is the 
interface to the machine architecture. At its lowest level this is manifest as a 
set of machine instructions together with other hardware resources such as 
registers and a memory model. 

It is generally expected that the programming language will hide the 
details of the architecture; this is after all its primary puipose. However, 
there are often architectural details that are not encapsulated in programming 
languages, such as the precision of floating point operations, or the 
organization of special memory models. Some languages include structures 
biased toward a particular architectural model, such as C with its orientation 
toward Digital PDP-11 and VAX architectures. Even if the language can 
hide the architecture completely, providing one or a few common 
architecture interfaces can greatly simplify compiler design. In the extreme, 
identical architectures across platforms can eliminate the need for 
recompilation, allowing for binary portability. 

For all of these reasons, we may want to consider strategies that provide 
greater standardization of the lower-level architectural interface. 

As usual we consider the three principal strategies of standardization, 
porting, and translation. Here we run into a problem. It is clear what is 
meant by standardizing an architecture, but how do we “port the machine?” 
Architecture translation may also seem impractical, but there are two 
different types of strategies that fit this description. 

In the end we can identify three distinct types of strategies at the 
architecture level. However, their relation to the three primary categories is 
a little more complicated. 

5.7.1 Standard Architectures 

The straightforward concept of a standard architecture is that a large 
collection of computers should have the same “machine-level” architecture 
(i.e., instruction set, registers, data types, memory model, etc.) even though 
they are produced by various companies. The clearest example of this 
concept is the de facto standard IBM-PC architecture, which is copied 
precisely by numerous “clones” made by companies other than IBM. 
Because the architecture is identical (except perhaps for a few details related 
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only to maintenance) all of the same software can be mn. There have been 
clones of systems as diverse as the IBM S/360, the Intel 8080 processor chip, 
and the Macintosh. 

A few formal architecture standards have also been developed. Japan's 
TRON project defined a microprocessor architecture which has actually been 
implemented by over a dozen companies. The Sun SPARC architecture has 
been approved as a formal standard, although it is not yet implemented 
outside of Sun. 

Today few users care greatly about the architecture of their computers, as 
long as they run the desired software and achieve good performance. 
However, companies that sell computers must be able to point to unique 
advantages of their product, which necessarily means differences. Makers of 
IBM clones try to meet this need by higher performance, lower cost, or 
better I/O devices. Other implementors may add extended features such as 
better memory management, but programs that rely on these features lose the 
benefits of portability. 

Occasionally success can be achieved by standardizing a limited part of 
the architecture. The IEEE binary floating point standard is now almost 
universally used in floating point hardware, and has greatly relieved a major 
portability problem for numerical software. 

5.7.2 Generic Architectures 

As an alternative to a standard architecture that is to be implemented by 
computing hardware directly, a common architecture may be defined which 
is intended to be “easily translated” into the physical architecture of a variety 
of computers. A common compiler can produce code for the generic 
architecture, and a machine-dependent translation converts this code into 
native instructions for each specific system. This may be an attractive 
approach if the translation step is simple and if the final performance of the 
software is not greatly reduced. 

The generic representation of the program may be viewed as a low-level 
intermediate form in the translation process. It may be translated to native 
machine code before execution, or it may be interpreted “on the fly.” 
Microprogrammed architectures may have the option of interpreting the 
generic machine code by a special microprogram. This option has become 
less common since the advent of RISC processors, which are usually not 
microprogrammed. 
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5.7.3 Binary Translation 

In previous discussions we have noted that significant adaptation is 
generally not practical for a program in “binary” (executable) form. In spite 
of this, there are times when it becomes essential to convert software already 
compiled for one architecture into a form that can be used on a very different 
architecture. Two well-known examples of this approach have arisen as 
major computer vendors migrated to newer, RISC-class architectures: 

• The change in Digital systems from the VAX to the Alpha 

• The change in Macintosh systems from the 68000 to the PowerPC 

In these situations a great deal of application software, already in 
executable form for the older environments, must be made to work in the 
newer one. To meet this need, strategies have evolved for effective binary 
translation as a transitional strategy. Typically, this approach uses a 
combination of translation before execution where possible, and run-time 
emulation otherwise. The success of the approach may rely on strong 
assumptions, such as the assumption that the program being translated is a 
well-behaved client of a particular operating system. 



6. THE SOFTWARE DEVELOPMENT PROCESS 

The previous section has identified a wide range of strategies for 
increasing portability by controlling the interfaces of a software unit. To put 
these strategies to work we must see how portability concerns fit into the 
software development process. 

The discussion in this section is focused on incorporating portability in a 
large-scale software development process. However, most of the 
recommendations may be applied to small projects as well. 

6.1.1 The Software Lifecycle 

A number of models of the software lifecycle are used both to understand 
the lifecycle and to guide the overall development strategy. These are 
surveyed in many software engineering texts, such as Sommerville (2000). 
Most widely known is the waterfall model, in which activities progress more 
or less sequentially through specification, design, implementation, and 
maintenance. Recently popular alternatives include rapid prototyping and 
the spiral model, with frequent iterations of the principal activities. Testing 




Developing Portable Software 



77 



(and debugging) and documentation may be viewed as distinct activities, but 
are usually expected to be ongoing throughout the process. 

Each of the principal activities of the lifecycle is associated with some 
distinct portability issues. However, the sequencing and interleaving of 
these activities, which distinguishes the models, does not substantially affect 
these issues. Thus our discussion is applicable across the usual models, but 
will focus primarily on the individual activities. 

6.1.2 Specification 

The purpose of a specification is to identify the functionality and other 
properties expected in the software to be developed. There are many 
proposed structures for such a specification, ranging from informal to fully 
formal, mathematical notations. Formal notations in current use express the 
functional requirements of a software product, but are not designed to 
express non-functional requirements such as reliability, performance, or 
portability. If such requirements exist they must be expressed by less formal 
means. 

We offer three guidelines for the specification activity to maxi mi ze 
portability, regardless of the form chosen for the specifications: 

1. Avoid portability barriers. It is important that a specification should not 
contain statements and phrases that arbitrarily restrict the target 
environment, unless those restrictions are conscious and intentional. For 
example, “the program shall prompt the user for an integer value” is 
better than “the program shall display a 2 by 3 inch text box in the center 
of the screen”. 

2. State constraints explicitly. It is important to know, for example, if the 
application must process a database with one million records or must 
maintain a timing accuracy of 5 milliseconds. This can be used in part to 
determine which target environments are reasonable. 

3. Identify target classes of environments. After consideration of the 
constraints and necessary portability barriers, the specification should 
identify the broadest possible class of target environments that may make 
sense as candidates for future porting. 

4. Specify portability goals explicitly. If the form permits, it is desirable to 
identify portability as a goal, and the tradeoffs that can be made to 
achieve it. An example might be “the program shall be developed to be 
easily ported to any interactive workstation environment, supporting at 
least thousands of colors, provided that development costs do not 
increase by more than 10% and performance does not decrease by more 
than 2% compared to non-portable development.” 
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6.1.3 Design 

Design is the heart of software development. Here our understanding of 
what the software is to do, embodied in the specification, directs the 
development of a software architecture to meet these requirements. At this 
stage the developer must select the approach to portability, and choose 
appropriate strategies. 

A large software project may require several levels of design, from the 
overall system architecture to the algorithms and data structures of 
individual modules. A systematic design method may be used, such as 
Structured Design, SADT, JSD, OOD, etc. The various methods have 
widely differing philosophies, and may lead to very different designs. 
However, they share a common objective: to identify a collection of 
elements (procedures, data structures, objects, etc.) to be used in 
implementing the software, and to define a suitable partitioning of these 
elements into modules. 

The resulting design (perhaps at various levels) has the form of a 
collection of interacting modules that communicate through interfaces. It is 
well understood that clear and careful interface design is a crucial element of 
good software design. 

Ideally, a software design is independent of any implementation and so is 
perfectly portable by definition. In practice, the choice of design will have a 
major impact on portability. 

Portability issues in design are focused on partitioning. We identify four 
guidelines: 

1. Choose a suitable methodology. Some design methods may be more 
favorable to portable design. For example, object-oriented design 
provides a natural framework for encapsulating external resources. 

2. Identify external interfaces. A systematic review of the functionality 
required by the software unit from its environment should lead to a 
catalog of external interfaces to be controlled. 

3. Identify and design to suitable standards. Standards should be identified 
that address interfaces in the catalog, and that are likely to be supported 
in the target environments. The design should organize these interfaces, 
as far as possible, in accordance with these standards. 

4. Isolate system-dependent interfaces. By considering the interfaces with 
no clear standard or other obvious strategy, and the intended class of 
target environments for porting, the developer can make reasonable 
predictions that these interfaces will need system-specific adaptation. 
These interfaces then become strong candidates for isolation. 
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6.1.4 Implementation 

Implementation is concerned with transforming a design into a working 
software product. If good design practice has been followed, the design in 
most cases should not be platform-specific, even if it is not explicitly 
portable. 

In most cases, the implementation targets one specific environment. 
Occasionally, versions for multiple environments are implemented 
simultaneously. During portable development, it is also possible to envision 
an implementation that has no specific target, but is ready for porting to 
many environments. 

Developers who strive for portability most frequently concentrate their 
attention on the implementation phase, so the issues here are fairly well 
understood. We offer three guidelines: 

1. Choose a portable language. If the language or languages to be used 

were not determined by the design phase, thy must be chosen now. Many 
factors go into good language choice, including programmer experience, 
availability of tools, suitability for the application domain, etc. An 
additional factor should be considered: is the language well 

standardized, widely implemented, and thus a good choice for 
portability? 

2. Follow a portability discipline. It is not enough to select a good 
language; the language should be used in a disciplined way. Every 
language has features that are likely to be portability problems. Any 
compiler features that check for portability should be enabled. 

3. Understand and follow the standards. The design phase and language 
choice have identified standards for use. The programmer must study and 
understand those standards, to be sure that the implementation actually 
matches what the standard says, and what will be expected on the other 
side of the interface. 

6.1.5 Testing and Debugging 

Testing is an essential activity for any type of software development. 
Many projects also make use of formal verification, to demonstrate a high 
l ik elihood of correctness by logical reasoning. However, this does not 
remove the need for testing. 

The goal of testing is to verify correct behavior by observation in a 
suitable collection of specific test cases. It is not possible to test all cases, 
but there are well-known techniques to generate sets of test cases that can 
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cover most expected situations and lead to a reasonably high confidence 
level in the correct operation of the software. 

Guidelines for the testing activity are: 

1. Develop a reusable test plan. A written test plan is always important. 
For portable software the test plan should be designed to be reused for 
new ported implementations. Based on design choices and experience to 
date, the plan should cleanly separate tests of system-dependent modules 
from tests of the modules that are common to all (or many) 
implementations. It should be anticipated that after porting, the same 
tests will be applicable to the common modules (and should produce the 
same results!). 

2. Document and learn from errors. A record should be kept, as usual, of all 
errors found, and the debugging strategies used to correct them. Again 
these records should be divided between common and system-dependent 
parts. Errors that have been corrected in common modules should not 
usually recur after a port. 

3. Don't ignore compiler warnings. Warnings from a compiler are often 
taken lightly, since they generally indicate a construct that is questionable 
but not considered a fatal error. If the program seems to work, the 
warning may be ignored. It is highly likely, though, that the problem 
identified by warnings means an increased likelihood of failure when 
running in a different environment. An unitialized variable may be 
harmless in one implementation, but cause incorrect behavior in the next. 

4. Test portability itself. If portability has been identified as an intended 
attribute in the specifications, it is necessary to test if this goalhas been 
achieved. This may require the use of portability metrics, discussed 
briefly below. 

6.1.6 Documentation 

Many types of documents are associated with a well-managed software 
process. Portability will have an impact on the documentation activity as 
well as the other development phases. 

Portability guidelines for documentation are: 

1. Develop portable documentation. The documentation phase offers an 
opportunity to take advantage of the commonality of portions of a 
software unit across multiple implementations. Technical documentation 
can be separated between the common part and the system-specific part. 
The common part will not change for new implementations. The same is 
true for user documentation, but with a caution: Users should be 
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presented with documentation that is specific for their environment, and 
avoids references to alternate environments. 

2. Document the porting process. The technical documentation should 
explain the aspects of the design that were provided for the sake of 
portability, and provide instructions for those who will actually port the 
software. 

6.1.7 Maintenance 

The maintenance phase is the payoff for portable development. Each 
requirement to produce an implementation in a new environment should be 
greatly facilitated by the efforts to achieve portability during original 
development. Other maintenance activities, such as error correction and 
feature enhancement, will not be impeded by portable design and may 
possibly be helped. 

The only complicating factor is the need to maintain multiple versions. 
Where possible, clearly, common code should be maintained via a single 
source, if the versions are under the control of a common maintainer. Issues 
of multiversion maintenance are widely discussed in the literature and will 
not be repeated here. 

6.1.8 Measuring Success 

An important management concern is to demonstrate with facts and 
figures that making software portable is a good idea, as well as to show that 
this goal has been achieved. Metrics are required to evaluate portability in 
this way. One useful metric is the degree of portability, defined as: 

DP = 1 - (cost of porting) / (cost of redevelopment) 

This metric may be estimated before beginning a porting project by 
comparing the estimated cost of porting with that of redevelopment, using 
standard cost estimation techniques. Note that the elements of the cost must 
be considered in the context of a specific target environment or class of 
environments. Degree of portability has no meaning without this context. 

The main difference between the two cost alternatives is that porting 
begins with adaptation, while redevelopment begins with redesign and 
reimplementation. 

If DP < 0, porting is more costly and should be avoided. If DP >= 0, then 
it will range between 0 and 1. In this case porting is the preferred solution, 
and the vale of DP is proportional to the expected cost of porting. 
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This metric may be estimated before initial development, to determine if 
portable development is worthwhile. It may also be estimated after initial 
development to characterize the portability that has been achieved. 



7. OTHER ISSUES 

This section briefly overviews two additional areas of concern that need 
to be considered for a more complete understanding of the software 
portability problem. 

7.1.1 Transportation and Data Portability 

We have identified two major phases of porting: adaptation and 

transportation. So far we have focused on adaptation issues. Transportation 
addresses problems of physical movement of software and associated 
artifacts, whether by means of transportable media or a network. This phase 
also must contend with a number of problems of data representation. 
Transportation issues can be identified in several categories: 

• Media Compatibility. There may be no common media format between 
the source and target environments. Even if both accept floppy disks, for 
example, there are different sizes, densities, and formats. The physical 
drive must accept the media from a different system, and it must further 
understand the information that is on it. 

• Network compatibility. A similar problem can occur if two systems are 
connected by a network. In this case differences in network protocols 
can present effective communication. 

• Naming and file systems. The problem is more complex if the data to be 
transported represents a set of files for which names and relationships 
must be maintained. There are dozens of file system types, and no 
standard format for data transport. Each environment understands only a 
limited number of “foreign” file systems, and may have different mles 
about file naming. 

• Data compatibility. Low level data issues may occur due to differences 
in character codes supported, different strategies for indicating line 
endings, different rules on byte order for multibyte integers, etc. The 
problems are more complex if data is to be transported in formats such as 
floating point or structures or arrays. 
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7.1.2 Cultural Adaptation 

It is not always desirable that ported software behave in exactly the same 
way as the original. There are many reasons why different behavior may be 
wanted. Many though not all of these are related to the user interface. We 
define the process of meeting the varying behavioral needs of each 
environment as cultural adaptation. This may take several forms: 

1. Adapting to user experience. The type of user interface preferred by a 
travel agent for booking airline flights is very different than that preferred 
by a casual user. In the same way, a user experienced with Macintosh 
systems will not want a new application to behave like a Windows 
program, unless they are even more familiar with the Windows version of 
that application. 

2. Adapting to human cultures. This involves many processes identified 
under the heading of internationalization and localization. It may be 
necessary to translate all text, including labels, etc., to different languages 
with very different structure from the original. In addition, issues as 
diverse as the sort order for databases or the use of color to convey 
certain meanings must be reconsidered. 

3. Adapting to environment capabilities and constraints. One example of 
this is the need to use different computational algorithms for different 
high-performance parallel computers. Another is the problem of 
economic portability (Murray-Lasso 1990). Many users in schools, non- 
profit agencies, or less developed countries continue to work with 
computers much less capable than today’s state-of-the-art. To avoid 
leaving these users behind, software should be adaptable to these older 
environments, even if its performance and functionality are reduced. 

8. CONCLUSION 

This paper has surveyed a broad range of issues to be considered in the 
development of portable software. A range of strategies has been proposed 
for addressing the problems. We have also examined ways in which 
portability may be incorporated into the software development process. 

We have only been able, however, to explore the surface of the problem. 
Some of the issues that have not been discussed are: 

• Tools for developing portable software 

• Analysis of costs and benefits 

• The porting process itself 

• Portability for special domains, such as parallel and real-time software 

• The relationship between portability and reuse 
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Portability vs. reuse is discussed by Mooney (1995). Most ofthese issues 
are examined in a course taught by the author at West Virginia University 
(Mooney 1992). More information is available on the course website 
(Mooney 2004). 
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Abstract Formal reasoning in the sense of “letting the symbols do the work” was 
Leibniz’s dream, but making it possible and convenient for everyday 
practice irrespective of the availability of automated tools is due to the 
calculational approach that emerged from Computing Science. 

This tutorial provides an initiation in a formal calculational approach 
that covers not only the discrete world of software and digital hardware, 
but also the “continuous” world of analog systems and circuits. The 
formalism ( Funrnath ) is free of the defects of traditional notation that 
hamper formal calculation, yet, by the unified way it captures the con- 
ventions from applied mathematics, it is readily adoptable by engineers. 

The fundamental part formalizes the equational calculation style 
found so convenient ever since the first exposure to high school algebra, 
followed by concepts supporting expression with variables (pointwise) 
and without (point-free). Calculation rules are derived for (i) propo- 
sition calculus, including a few techniques for fast “head” calculation; 
(ii) sets; (iii) functions, with a basic library of generic functionals that 
are useful throughout continuous and discrete mathematics; (iv) pred- 
icate calculus, making formal calculation with quantifiers as “routine” 
as with derivatives and integrals in engineering mathematics. Pointwise 
and point-free forms are covered. Uniform principles for designing con- 
venient operators in diverse areas of discourse are presented. Mathemat- 
ical induction is formalized in a way that avoids typical errors associated 
with informal use. Illustrative examples are provided throughout. 

The applications part shows how to use the formalism in computing 
science, including data type definition, systems specification, imperative 
and functional programming, formal semantics, deriving theories of pro- 
gramming, and also in continuous mathematics relevant to engineering. 



Keywords: Analysis, calculational reasoning, data types, functional predicate cal- 

culus, Funrnath, generic functionals, programming theories, quantifiers 
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Introduction: motivation and overview 

Motivation. Parnas [26] notes that professional engineers can be dis- 
tinguished from other designers by their ability to use mathematics. In 
classical (electrical, mechanical) engineering this ability is de facto well- 
integrated. In computing it is still a remote ideal or very fragmented at 
best; hence the many urgings to integrate formal methods throughout all 
topics [15, 32]. According to Gopalakrishnan [15], the separate appella- 
tion “formal methods” would be redundant if mathematics was practiced 
in computing as matter-of-factly as in other branches of engineering. 

Still, computing needs a more formal mathematical style than classi- 
cal engineering, as stressed by Lamport [23]. Following Dijkstra [14] and 
Gries [16], “formal” is taken in the usual mathematical sense of manip- 
ulating expressions on the basis of their form (syntax) rather than some 
interpretation (semantics). The crucial benefit is the guidance provided 
by calculation rules, as nicely captured by the maxim “Ut faciant opus 
signa” of the Mathematics of Program Construction conferences [5]. 

In applied mathematics and engineering, calculation with derivatives 
and integrals is essentially formal. Readers who enjoyed physics will 
recall the excitement when calculation pointed the way in case seman- 
tic intuition was clueless, showing the value of parallel syntactic intu- 
ition. Algebra and analysis tools (Maple, Mathematica etc.) are readily 
adopted because they stem from formalisms meant for human use (hand 
calculation), have a unified basis and cover a wide application spectrum. 

Comparatively, typical logical arguments in theory development are 
informal, even in computing. Symbolism is often just syncopation [29], 
i.e., using logic symbols as mere shorthands for natural language, such 
as V and 3 abbreviating “for all” and “there exists”. This leaves formal 
logic unexploited as a reasoning aid for everyday mathematical practice. 

Logic suffers from the historical accident of having had no chance to 
evolve into a proper calculus for humans [14, 18] before attention shifted 
to mechanization (even before the computer era). Current logic tools 
are not readily adopted and need expert users. Arguably this is because 
they are not based on formalisms suited for human use (which includes 
“back-of-an-envelope” symbolic calculation). Leading researchers [27] 
warn that using symbolic tools before mental insight and proficiency in 
logic is acquired obscures elements that are crucial to understanding. 

This tutorial bridges the essential gaps. In particular, it provides a 
formalism (F unmath) by which engineers can calculate with predicates 
and quantifiers as smoothly as with derivatives and integrals. In addition 
to direct applicability in everyday mathematical practice whatever the 
application, it yields superior insight for comparing and using tools. 
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Overview. Sections 1-3 cover preliminaries and the basis of the for- 
malism: functional predicate calculus and generic functionals. Sections 
4-6 show applications in diverse areas of computing and “continuous” 
mathematics. Due to page limitations, this is more like an extended syl- 
labus, but a full 250-page course text [10] is available from the author. 

1. Calculating with expressions and propositions 

A formalism is a language ( notation ) plus formal calculation rules. 
Our formalism needs only four language constructs. Two of these (sim- 
ilar to [17]) are covered here, the other two appear in later sections. 

1.1 Expressions, substitution and equality 

Syntax conventions. The syntax of simple expressions is defined by 
the following BNF grammar. Underscores designate terminal symbols. 

expression ::= variable \ constanto \ application 
application (copi expression) \ (expression cop2 expression) 

Here variable, constanto , copi en cop 2 are domain-dependent. Example: 
with variable ::= x \ y | z and constanto a \ b \ c and operators 
defined by copi succ \ pred and cop 2 ::= + I j we obtain 

expressions like ‘a’ V \succy)' fa + yf ‘((a • (succx)) + y)\ 

When clarity requires, we use quotes ‘ ’ for strings of terminals, and 
1 1 if metavariables may be present. Lowercase words (e.g., expression) 
designate a nonterminal, the first letter in uppercase (e.g., E) the cor- 
responding syntactic category, i.e., set of symbol strings, and the first 
letter itself (e.g., e) is a metavariable for a string in that set. Example: 
let metavariables v, c, <f>, * correspond to V, Co, C\, C2, and e, e' to E; 
then [v], [cj, {{f e)J, [(e*e')J represent all forms of simple expressions. 

Parentheses can be made optional by the usual conventions. We define 
formulas by formula ::= expression = expression, as in x • y — y ■ x. 

Substitution. Replacing every occurrence of variable v in expression 
e by expression d is written e[v := d\ and formalized recursively by 

Sv: w[v := d] = (v = w) ? d \ w for variable v in V 

SO: c\v d\ = c for constant c in Co 

SI: ( <f>e)[v := d] = ( <f>e[v := d]) for <j> in C\ and e in E 

S 2 : {e*e')[v := d] = (e[v := d] *e'[i> := d]) for ★ in C2] e, e' in E 

All equalities here are purely syntactic (not part of formulas). Expres- 
sions like c ? b ] a (as in Sv) are understood as “if c then 6 , else a” . 
Example: for (o • succ x + y)[x := z • o] the rules yield ‘o • succ (z ■ a) + y\ 
Multiple (parallel) substitution is a straightforward generalization. 
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Deduction and equational reasoning Later on we shall see formu- 
las other than equality. Generally, an inference rule is a little “table” 

Prems 



Q 

where Prems is a set of formulas called premisses and q a formula called 
the conclusion. Inference rules are used as follows. 

A consequence of a set Hyps of formulas (called hypotheses) is ei- 
ther one of the hypotheses or the conclusion of an inference rule whose 
premisses are consequences of Hyps. A deduction is a record of these 
correspondences. We write Hyps (— q if q is a consequence of Hyps. 

Axioms are selected hypotheses (application-dependent). Theorems 
are consequences of axioms, and proofs are deductions of theorems. 

The main inference rules are instantiation and the rules for equality. 



a. Instantiation (strict): 

b. Leibniz’s principle (not strict): 

c. Symmetry of equality (not strict): 

d. Transitivity of equality (not strict): 



p[v := e] 
d = d' 

e[v d'] — e[v d' r 



e" = c! 

Z^i 77 

e = e', e 7 = 
e^e n ~ 



A strict inference rule requires that its premisses are theorems. 
In the equational style, deductions are recorded in the format 



e = (justification) e' 

— (justification) e" etc. 



( 1 ) 



The inference rules are fitted into this format as follows. 

a. Instantiation In equational reasoning, premiss p is a theorem of 
the form d' = d" , hence the conclusion p[v := e] is (d! — d")[v e ] which 
has the form e' = e". Example: (a -f b) ■ c ={x ■ y = y ■ x) c • (a + b). 

b. Leibniz Premiss p is of the form d' = d" and the conclusion is 
e[v := d!] = e[v := d"], which has the form e' — e" . Example: with 
premiss y — a • x we may write x + y =(y — a ■ x) x + a ■ x. 

c. Symmetry Premiss p is of the form e /7 = e' and the conclusion is 
e' = e" . However, this simple step is usually taken tacitly. 

d. Transitivity has two equalities for premisses. It is used implicitly 
to justify chaining e = e! and e! — e" as in (1) to conclude e = e" . 



1.2 Pointwise and point-free styles of expression 

One can specify functions pointwise by referring to points in the 
domain, as in square x = x 2 , or point-free using functionals, as in 
square = multiply o duplicate (comment needed nor given at this stage). 
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The respective archetypes of these styles are lambda terms and com- 
binator terms, briefly discussed next to capture the essence of symbolic 
manipulation in both styles in an application-independent form. 

Syntax of lambda terms. Bound and free occurrences. The 

syntax for lambda terms [2 ] is defined by the following BNF grammar. 

term variable \ (term term) \ (Xvariable derm). (2) 

Examples: x ( xy ) ( Xx.(((y(Xx.(Xy.((xz)(Xz.((xy)z))))))y)z )) 

Naming convention A is the syntactic category and L..R metavari- 
ables for terms; it, v, w metavariables for variables; x, y, z are typical 
variables, and symbols like C, D, I, K, S abbreviate often-used terms. 

Terminology A term like (MN) is an application, ( Xv.M ) is an ab- 
straction: Xv. is the abstractor and M (the scope of Xv.) the abstrahend. 

Parentheses convention Outer parentheses are optional in (MN) 
and in (Xv.M) if these terms stand alone or as an abstrahend. Hence 
the scope extends as far as parentheses permit. Application associates 
to the left, (LMN) standing for (( LM)N ). Nested abstractions like 
Xu.Xv.M are written Xuv.M. Example: Xx.y(Xxy.xz(Xz.xyz))yz stands 
for (Xx.(((y(Xx.(Xy.((xz)(Xz.((xy)z))))))y)z)), saving 18 parentheses. 

Bound and free occurrences Every occurrence of v in Xv.M is bound. 
Occurrences that are not bound ar efree. Example: numbering variable 
occurrences in Xx.y(Xxy.xz(Xz.xyz))yz from 0 tot 11, the only free ones 
are those of y and z at places 1, 5, 10 and 11. We write <p M for the set 
of variables with free occurrences in M, for instance ip‘X z.xyz' — {x,y}. 

Substitution and calculation rules (lambda-conversion). Sub- 
stituting Lfor w in M, written M[w := L\ or M[“, is defined recursively: 

Svar: v[™ — (v = w) ? L \ fuj 

Sapp: (MN)IJ = (M[f JV[J) 

Sabs: (Xv.M)[f = (Xu.M[^[f) for fresh u 

The fresh variable u in Sabs prevents free variables in L becoming bound 
by Xv., as in the erroneous elaboration (Xx.xy)[x = Xx.xx, which should 
have been (Xx.xy)\x — Xz.zx. 

The calculation rules firstly are those for equality: symmetry, transi- 
tivity and Leibniz’ s principle, i.e., z\v=M\=L\v'=N] • P ro P er axioms are: 

a-conversion: (Xv.M) = (Aia.M[^) provided w pM 
/3-conversion: (Xv.M)N = M[ V N 

For instance, (Xxy.xy) = a Xxz.xz and (Xxy.xy)y =p Xz.yz. 
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Additional axioms yield variants. Examples are: rule £: \ v ,m=\v.N , 
rule r) (or ^-conversion): (A v.Mv) = M (provided v (cM) and rw/e 
£ (extensionality): provided v $ <p(M,N ). As an additional 

axiom (assuming a and (3), rule £ is equivalent to £ and r) combined. 

Henceforth we assume a, (3 and extensionality, i.e., “everything”. Ex- 
amples of reconversion are (A x.yzx) =,, yz and A xy.xy = v Xx.x. 

Redexes, normal forms and closed terms. A termlike (Xv.M)N 
is a (3-redex and A v.Mv (with v $. <pM) is a rj-redex. A /3r)-normal form 
(or just “normal form”) is a term not containing a /?- or ry-redex. A term 
“has a normal form” if it can be reduced to a normal form. According to 
the Church-Rosser theorem, a term has at most one normal form. The 
term ( Xx.xx)(Xx.xx ) even has none. 

Closed terms or (lambda -)combinators are terms without free vari- 
ables. Beta-conversion can be encapsulated by properties expressed us- 
ing metavariables. For instance S, standing for Xx yz.xz(yz), has prop- 
erty S PQR = PR(QR) by /?- conversion. 



Expressions without variables: combinator terms. Syntax: 

term K \ S \ (term term) (3) 

where K and S are constants (using different font to avoid confusion 
with lambda-combinators). As before, LMN stands for (( LM)N ). 

The calculation rules firstly are those for equality. By lack of variables, 
Leibniz’s principle is and fJtlZddL • The proper axioms are 

KLM = L and SPQR = PR(QR) 



and extensionality: if M en N satisfy ML = NL for any L, then M = N. 

E.g., SKMN '= { SPQR = PR{QR )) KN(MN) = ( KLM = L) N. 
Hence, defining I as SKK yields an identity operator: IN = N. 

Converting combinator terms into (extensionally) equal lambda com- 
binators is trivial. For the reverse, define for every w an operator [in]: 



For variables w: [w]w = I 

For variables v w): [io]u = Kv 

For constants c: [u>]e = Kc 

For applications: [w](MN) = 5([iw]M)([u)]AT) 

For abstractions: [ w\(Xv.M ) = [u>]([u]M) 



(Rule I) 
(Rule K’) 
(Rule K”) 
(Rule S) 
(Rule a bs) 



The crucial property of this operator is Xw.M = [w]M. 

There are two important shortcuts: provided w y> M, we can use 
[w](Mw) — M (Rule rf) and [w\M = KM (Rule K), the latter being a 
more efficient replacement for both (K’) and (K”). Example: A xyz.xzy 
—(Xw.M = [w]M) [x\([y]([z]xzy)) =(rules) S(S(KS)(S(KK)S))(KK). 




